内容

はじめに

背景説明

前提条件

要件

使用するコンポーネント

表記法

STP障害の原因

転送ループのトラブルシューティング

1.ループの識別

2.ループのトポロジ（範囲）の検出

3.ループの解除

4.ループの原因の発見と修正

5.冗長性の復元

トポロジ変更の調査

フラッディングの原因の特定

TCの発生源の特定

過度の TC を防ぐための処置

コンバージェンス時間関連の問題のトラブルシューティング

STP debugコマンドの使用

フォワーディングループからのネットワークの保護

1.すべてのスイッチ間リンクで単方向リンク検出(UDLD)を有効にする

2.すべてのスイッチでループガードを有効にする

3.すべてのエンドステーションポートでPortFastを有効にする

4.両側のEtherChannelをDesirableMode（サポートされている場合）およびNon-SilentOptionに設定する

5.スイッチ間リンクでオートネゴシエーションを無効にしない（サポートされている場合）

6. STPタイマーを調整する際には注意が必要です

7.サービス拒絶攻撃を受ける可能性がある場合は、ルートガードを使用してネットワークSTP境界を保護します

8. PortFast対応ポートでBPDUガードを有効にして、ポートに接続された不正なネットワークデバイス（ハブ、スイッチ、ブリッジングルータなど）によるSTPの影響を防止します

9.管理VLANでのユーザトラフィックの回避

10.予測可能な（ハードコードされた）STPルートとバックアップSTPルートの配置

関連情報

はじめに

このドキュメントでは、Cisco IOS®ソフトウェアを使用してスパニングツリープロトコル(STP)の問題をトラブルシューティングする方法について説明します。

背景説明

Catalyst 6500/6000だけに適用される特定のコマンドもありますが、原則のほとんどは、Cisco IOSソフトウェアが稼働するすべてのCisco Catalystスイッチに適用できます。

ほとんどのSTPの問題には、次の3つの問題があります。

- フォワーディング ループ.

- STPトポロジ変更(TC)が頻繁に発生することによる過剰なフラッディング

- コンバージェンス時間に関する問題.

ブリッジには、特定のパケットが複数回転送されるかどうかを追跡するメカニズムがないため（たとえば、IP Time to Live [TTL]）、ネットワーク内で長時間循環するトラフィックを廃棄するために使用されます。同じレイヤ2(L2)ドメイン内の2つのデバイス間に存在できるパスは1つだけです。

STPの目的は、STPアルゴリズムに基づいて冗長ポートをブロックし、冗長な物理トポロジをツリー状のトポロジに解決することです。フォワーディング ループ（STP ループなど）は、冗長トポロジ内にブロックされるポートがない場合に発生します。フォワーディング ループが発生すると、トラフィックは際限なくネットワーク内を循環します。

転送ループが始まると、パスに沿って最も低い帯域幅のリンクが輻輳します。すべてのリンクが同じ帯域幅の場合、すべてのリンクが輻輳します。この輻輳によりパケット損失が発生し、影響を受けるL2ドメインでネットワークのダウン状態が発生します。

過剰なフラッディングがあると、症状はそれほど明らかではありません。低速リンクは、フラッディングされたトラフィックによって輻輳する可能性があり、輻輳したリンクの背後にあるデバイスやユーザでは、遅延が発生したり、接続が完全に失われたりする可能性があります。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- 各種スパニングツリーのタイプとその設定方法。詳細については、『STPおよびIEEE 802.1s MSTの設定』を参照してください。

- 各種スパニングツリーの機能とその設定方法。詳細は、『STP機能の設定』を参照してください。

使用するコンポーネント

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

- スーパーバイザ 2 エンジン搭載の Catalyst 6500

- Cisco IOS ソフトウェア リリース 12.1(13)E

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

表記法

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

STP障害の原因

STP には、動作環境に関して特定の前提条件があります。このドキュメントに関連する前提条件は、次のとおりです。

- 2 つのブリッジ間の各リンクは双方向である。つまり、AがBに直接接続している場合、AはBが送信した内容を受信し、BはAが送信した内容を受信します（リンクがBとBの間でアップしている限り）。

- STPを実行する各ブリッジは、STPブリッジプロトコルデータユニット(BPDU)（STPパケットとも呼ばれる）を定期的に受信、処理、および送信できます。

これらの前提条件は論理的で当たり前のように思われますが、これらの前提条件が満たされない状況があります。これらの状況のほとんどは、一種のハードウェアの問題に関係しますが、ソフトウェアの不具合によってSTP障害が発生する場合もあります。さまざまなハードウェア障害、誤設定、接続の問題がSTP障害の大部分を引き起こしているのに対し、ソフトウェア障害は少数派を占めています。また、スイッチの間に不必要な接続が追加された場合にも STP の障害が発生する場合があります。それらの追加接続によって、VLAN がダウン状態になります。この問題を解決するには、スイッチ間の不必要な接続をすべて削除します。

これらの前提条件の1つが満たされない場合、1つ以上のブリッジがBPDUを受信または処理できません。これは、ブリッジがネットワークトポロジを検出していないことを意味します。正しいトポロジを認識していないと、スイッチはループをブロックできません。したがって、フラッディングされたトラフィックはループされたトポロジを循環し、すべての帯域幅を消費してネットワークをダウンさせます。

スイッチがBPDUを受信できない原因の例としては、不良トランシーバやGigabit Interface Converter（GBIC；ギガビットインターフェイスコンバータ）の障害、ケーブルの問題、ポート、ラインカード、またはスーパーバイザエンジンのハードウェア障害などがあります。多くの STP 障害の原因になっています。このような条件では、1 台のブリッジが BPDU を送信しても、下流側のブリッジではこれが受信されません。STP処理は、スイッチが受信したBPDUを処理できないため、CPUの過負荷（99 %以上）によって中断される可能性もあります。BPDU も一方のブリッジから他方のブリッジへのパスを通る間に破損する可能性があり、これにより STP の正常な動作も妨げられます。

フォワーディングループ以外に、ブロックされるポートがない場合、トラフィックをブロックするポートを通じて特定のパケットだけが誤って転送される状況があります。このようなケースは、ソフトウェアの問題によるものがほとんどです。このような動作は「スローループ」を引き起こす可能性があります。 これは、一部のパケットがループしているが、リンクが輻輳していないために、トラフィックの大部分が引き続きネットワークを通過していることを意味します。

転送ループのトラブルシューティング

フォワーディング ループは、その発生（原因）と影響の両方において実に多種多様です。STP に影響を与える問題は多岐に渡るので、このドキュメントでは、フォワーディング ループに関するトラブルシューティングの一般的なガイドラインだけを説明します。

トラブルシューティングを開始する前に、次の情報が必要です。

- すべてのスイッチとブリッジの詳細が示された実際のトポロジ図.

- 対応するポート番号（相互接続）。

- STP設定の詳細。たとえば、どのスイッチがルートおよびバックアップルートであるか、どのリンクにデフォルト以外のコストまたはプライオリティが設定されているか、トラフィックをブロックしているポートの位置がどれであるかといった詳細です。

1.ループの識別

ネットワーク内でフォワーディングループが発生した場合、通常は次のような症状が現れます。

- ループの影響を受けるネットワーク領域との両方向の接続、およびそのネットワークを介した接続が失われる。

- ループの影響を受けるセグメントまたは VLAN と接続されたルータの CPU 使用率が高くなり、ルーティング プロトコルの近接ルータのフラッピングや Hot Standby Router Protocol（HSRP; ホットスタンバイ ルータ プロトコル）のアクティブ ルータの

- リンク使用率が高くなる（多くの場合 100 %）。

- スイッチ バックプレーンの使用率が高くなる（ベースライン使用率と比較して）。

- ネットワーク内のパケットループを示すsyslogメッセージ（HSRP重複IPアドレスメッセージなど）。

- アドレスの再学習が常に行われていることを示す Syslog メッセージや、MAC アドレスのフラッピング メッセージが表示される。

- 多くのインターフェイスで廃棄される出力数が増加します。

これらの理由のいずれかが単独で異なる問題を示している可能性があります（または、まったく問題がない可能性があります）。しかし、上記のうち、多くの症状が同時に見られる場合は、そのネットワーク内でフォワーディング ループが発生している可能性が十分考えられます。フォワーディング ループが発生しているかどうかを確認する最も速い方法は、スイッチのバックプレーン トラフィックの使用率を確認することです。

cat#show catalyst6000 traffic-meter

traffic meter =   13%  Never cleared

peak =   14%  reached at 12:08:57 CET Fri Oct 4 2002

注:Cisco IOSソフトウェアが稼働するCatalyst 4000では、現在このコマンドはサポートされていません。

現在のトラフィックレベルが過剰であるか、またはベースラインレベルが不明な場合は、最近ピークレベルに達したかどうかと、ピークレベルが現在のトラフィックレベルに近いかどうかを確認します。たとえば、ピーク時のトラフィックレベルが15 %で、そのレベルに達したのがわずか2分前であり、現在のトラフィックレベルが14 %であったとすると、スイッチの負荷が異常に高いことを意味します。トラフィックが通常のレベルである場合は、ループが発生していないか、このデバイスがループとは関係がないことのいずれかを意味します。ただし、スロー ループに関係している可能性は残ります。

2.ループのトポロジ（範囲）の検出

ネットワークの停止原因がフォワーディング ループであることが特定されたら、そのループを停止させネットワーク機能を回復させることが、最優先の処理です。

ループを停止するには、ループに参加しているポートを把握する必要があります。リンク使用率が最も高いポート（1秒あたりのパケット数）を確認します。show interfaceCisco IOSソフトウェアコマンドは、各インターフェイスの使用率を表示します。

使用率の情報とインターフェイス名だけを表示するには（簡単に分析するため）、Cisco IOSソフトウェアで一般的な式の出力をフィルタリングします。theshow interfaceを発行します。 | include line|\/seccommandコマンドを実行すると、パケット/秒の統計情報とインターフェイス名のみが表示されます。

cat#show interface | include line|\/sec

GigabitEthernet2/1 is up, line protocol is down

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

GigabitEthernet2/2 is up, line protocol is down

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

GigabitEthernet2/3 is up, line protocol is up

5 minute input rate 99765230 bits/sec, 24912 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

GigabitEthernet2/4 is up, line protocol is up

5 minute input rate 1000 bits/sec, 27 packets/sec

5 minute output rate 101002134 bits/sec, 25043 packets/sec

GigabitEthernet2/5 is administratively down, line protocol is down

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

GigabitEthernet2/6 is administratively down, line protocol is down

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

GigabitEthernet2/7 is up, line protocol is down

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

GigabitEthernet2/8 is up, line protocol is up

5 minute input rate 2000 bits/sec, 41 packets/sec

5 minute output rate 99552940 bits/sec, 24892 packets/sec

リンク使用率が最も高いインターフェイスに注意してください。この例では、インターフェイスg2/3、g2/4、およびg2/8です。これらはループに参加するポートです。

3.ループの解除

ループを遮断するには、関係するポートをシャットダウンするか接続解除します。ループを停止するだけでなく、ループの根本原因を見つけて修正することも特に重要です。ループを切断する方が比較的簡単です

注：すべてのポートを同時にシャットダウンしたり、接続解除したりする必要はありません。一度に1つずつシャットダウンできます。ディストリビューションスイッチやコアスイッチなど、ループの影響を受けるアグリゲーションポイントでポートをシャットダウンすることをお勧めします。すべてのポートを一度にシャットダウンし、1つずつイネーブルにするか、再接続すると、ループは機能しません。障害のあるポートが再接続された直後には、ループは停止し、すぐに開始できなくなります。したがって、障害を特定のポートに関連付けることは困難です。

注：ループを解消するために、スイッチをリブートする前に情報を収集することを推奨します。そうしないと、その後の根本原因の分析が困難になります。 各ポートをディセーブルにしたり、接続解除した後は、スイッチのバックプレーンの使用率が通常のレベルに戻っているかどうかを確認してください。

注：ポートはループを維持しませんが、ループで着信するトラフィックをフラッディングしています。このようなフラッディングポートをシャットダウンしても、バックプレーンの使用率はわずかしか低下しませんが、ループは停止しません。

次のトポロジ例では、ループはスイッチA、B、およびDの間にあります。したがって、リンクAB、AD、およびBDが維持されます。これらのリンクのいずれかをシャットダウンすると、ループが停止します。リンクAC、AE、BC、およびBEは、ループで到着するトラフィックを単にフラッディングしているだけです。

ループおよびフラッディングされたトラフィック

サポートポートがシャットダウンされると、バックプレーンの使用率が正常値まで低下します。どのポートのシャットダウンによってバックプレーンの使用率（および他のポートの使用率）が通常のレベルに戻ったかを知る必要があります。

この時点でループが停止し、ネットワークの動作が改善されますが、ループの元の原因が修正されていないため、他の問題が残っています。

4.ループの原因の発見と修正

ループが停止したら、ループが発生した原因を特定する必要があります。理由はさまざまであるため、これはプロセスの難しい部分です。またこの作業は、どのケースにも有効な手順として、正確に定型化することが難しい作業でもあります。

ガイドライン：

- トポロジダイアグラムを調べて、冗長パスを見つけます。これには、前のステップで見つかった同じスイッチに戻るサポートポート（ループ中に交換されたパスパケット）が含まれます。前のトポロジの例では、このパスは AD-DB-BA です。

- 冗長パス上のすべてのスイッチについて、スイッチが正しいSTPルートを認識しているかどうかを確認します。

L2ネットワーク内のすべてのスイッチは、共通のSTPルートに合意する必要があります。ブリッジが常にある特定の VLAN または STP インスタンスに対して異なる ID を表示するときは、問題の症状がはっきりと現れているときです。show spanning-tree vlan vlan-idコマンドを発行して、特定のVLANのルートブリッジIDを表示します。

cat#show spanning-tree vlan 333

MST03

Spanning tree enabled protocol mstp

Root ID    Priority    32771

Address     0050.14bb.6000

Cost        20000

Port        136 (GigabitEthernet3/8)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)

Address     00d0.003f.8800

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role Sts Cost      Prio.Nbr Status

---------------- ---- --- --------- -------- ------------------------

Gi3/8            Root FWD 20000     128.136  P2p

Po1              Desg FWD 20000     128.833  P2p

この VLAN 番号は、ポートから見つけることができます。ループに関係するポートは前述のステップで判明しているからです。問題のポートがトランクである場合、そのトランク上のすべての VLAN が関係していることが度々あります。そうでない場合（たとえば、単一のVLANでループが発生したように見える場合）は、showインターフェイスを発行してみることができます | include L2|line|broadcastcommand（Catalyst 6500/6000シリーズスイッチのSupervisor 2以降のエンジンの場合のみ。Supervisor 1ではVLAN単位のスイッチング統計情報が提供されないため）VLANインターフェイスのみを確認します。多くの場合、ループが発生したのは、スイッチ導入パケットの数が最も多いVLANです。

cat#show interface | include L2|line|broadcast

Vlan1 is up, line protocol is up

L2 Switched: ucast: 653704527 pkt, 124614363025 bytes - mcast:

23036247 pkt, 1748707536 bytes

Received 23201637 broadcasts, 0 runts, 0 giants, 0 throttles

Vlan10 is up, line protocol is up

L2 Switched: ucast: 2510912 pkt, 137067402 bytes - mcast:

41608705 pkt, 1931758378 bytes

Received 1321246 broadcasts, 0 runts, 0 giants, 0 throttles

Vlan11 is up, line protocol is up

L2 Switched: ucast: 73125 pkt, 2242976 bytes - mcast:

3191097 pkt, 173652249 bytes

Received 1440503 broadcasts, 0 runts, 0 giants, 0 throttles

Vlan100 is up, line protocol is up

L2 Switched: ucast: 458110 pkt, 21858256 bytes - mcast:

64534391 pkt, 2977052824 bytes

Received 1176671 broadcasts, 0 runts, 0 giants, 0 throttles

Vlan101 is up, line protocol is up

L2 Switched: ucast: 70649 pkt, 2124024 bytes - mcast:

2175964 pkt, 108413700 bytes

Received 1104890 broadcasts, 0 runts, 0 giants, 0 throttles

上記の例では、VLAN 1 に最も多くの数のブロード キャストおよび L2 交換トラフィックがあることがわかります。 ルートポートが正しく識別されていることを確認します。

ルートポートは、ルートブリッジへのコストが最も低いポートである必要があります（ホップの観点では1つのパスが短く、コストの観点では長くなる場合があります。低速ポートの方がコストが高いためです）。 どのポートが特定のVLANのルートと見なされているかを判断するには、show spanning-tree vlanコマンドを発行します。

cat#show spanning-tree vlan 333

MST03

Spanning tree enabled protocol mstp

Root ID    Priority    32771

Address     0050.14bb.6000

Cost        20000

Port        136 (GigabitEthernet3/8)

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)

Address     00d0.003f.8800

Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Interface        Role Sts Cost      Prio.Nbr Status

---------------- ---- --- --------- -------- ------------------------

Gi3/8            Root FWD 20000     128.136  P2p

Po1              Desg FWD 20000     128.833  P2p

BPDUがルートポートとブロック対象のポートで定期的に受信されていることを確認します。

BPDUはevery hellointerval(デフォルトでは2秒)にルートブリッジから送信されます。ルート以外のブリッジは、ルートから送られる BPDU の受信、処理、修正および伝搬を行います。 BPDUが受信されているかどうかを確認するには、show spanning-tree interface interface detailコマンドを発行します。

cat#show spanning-tree interface g3/2 detail

Port 130 (GigabitEthernet3/2) of MST00 is backup blocking

Port path cost 20000, Port priority 128, Port Identifier 128.130.

Designated root has priority 0, address 0007.4f1c.e847

Designated bridge has priority 32768, address 00d0.003f.8800

Designated port id is 128.129, designated path cost 2000019

Timers: message age 4, forward delay 0, hold 0

Number of transitions to forwarding state: 0

Link type is point-to-point by default, Internal

Loop guard is enabled by default on the port

BPDU: sent 3, received 53

cat#show spanning-tree interface g3/2 detail

Port 130 (GigabitEthernet3/2) of MST00 is backup blocking

Port path cost 20000, Port priority 128, Port Identifier 128.130.

Designated root has priority 0, address 0007.4f1c.e847

Designated bridge has priority 32768, address 00d0.003f.8800

Designated port id is 128.129, designated path cost 2000019

Timers: message age 5, forward delay 0, hold 0

Number of transitions to forwarding state: 0

Link type is point-to-point by default, Internal

Loop guard is enabled by default on the port

BPDU: sent 3, received 54

注：コマンドの2つの出力の間に1つのBPDUが受信されました（カウンタは53から54になりました）。

表示されるカウンタは、STP プロセスによって実際に維持されるカウンタです。これは、受信カウンタが増加した場合、BPDUが物理ポートで受信されただけでなく、STPプロセスでも受信されたことを意味します。 If thereceived BPDUカウンタは、代替ルートポートまたはバックアップポートとなるはずのポートでは増加せず、ポートがマルチキャストを受信しているかどうか（BPDUはマルチキャストとして送信される）を確認します。次のように、show interface interface counterscommandコマンドを発行します。

cat#show interface g3/2 counters

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts

Gi3/2           14873036             2         89387             0

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts

Gi3/2          114365997         83776        732086            19

cat#show interface g3/2 counters

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts

Gi3/2           14873677             2         89391             0

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts

Gi3/2          114366106         83776        732087            19

STPポートの役割についての簡単な説明は、『ループガードとBPDUスキュー検出機能を使用したスパニングツリープロトコルの拡張』の「ループガードとBPDUスキュー検出によるSTPの拡張」セクションにあります。 BPDUが受信されない場合は、ポートでエラーがカウントされているかどうかを確認します。次のように、show interface interface counters errorscommandコマンドを発行します。

cat#show interface g4/3 counters errors

Port     Align-Err    FCS-Err   Xmit-Err    Rcv-Err UnderSize OutDiscards

Gi4/3        0          0          0          0         0           0

Port  Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen   Runts    Giants

Gi4/3       0         0         0          0         0        0         0

BPDU が物理ポートによって受信されてはいるものの、STP プロセスに達してしない可能性があります。前の2つの例で使用したコマンドを実行して、マルチキャストの一部が受信され、エラーがカウントされていないことが示された場合は、BPDUがSTPプロセスレベルで廃棄されているかどうかを確認します。Catalyst 6500でremote command switch test spanning-tree process-statscommandを発行します。

cat#remote command switch test spanning-tree process-stats

------------------TX STATS------------------

transmission rate/sec     = 2

paks transmitted          = 5011226

paks transmitted (opt)    = 0

opt chunk alloc failures  = 0

max opt chunk allocated   = 0

------------------RX STATS------------------

receive rate/sec          = 1

paks received at stp isr  = 3947627

paks queued at stp isr    = 3947627

paks dropped at stp isr   = 0

drop rate/sec             = 0

paks dequeued at stp proc = 3947627

paks waiting in queue     = 0

queue depth               = 7(max) 12288(total)

--------------PROCESSING STATS---------------

queue wait time (in ms)   = 0(avg) 540(max)

processing time (in ms)   = 0(avg) 4(max)

proc switch count         = 100

add vlan ports            = 20

time since last clearing  = 2087269 sec

この例で使用するコマンドは、STPプロセスの統計情報を表示します。ドロップカウンタが増加しないこと、および受信パケットが増加することを確認することが重要です。 受信パケットが増加していないのに、物理ポートがマルチキャストを受信している場合は、パケットがスイッチのインバンドインターフェイス（CPUのインターフェイス）で受信されていることを確認します。remote command switch show ibcを発行します。 | Catalyst 6500/6000のi rx_inputcommand:

cat#remote command switch show ibc | i rx_input

rx_inputs=5626468, rx_cumbytes=859971138

cat# remote command switch show ibc | i rx_input

rx_inputs=5626471, rx_cumbytes=859971539

この例では、2 回の出力の間に 23 個のパケットがインバンド ポートにより受信されたことを示しています。

注：これらの23個のパケットはBPDUパケットだけではありません。これは、インバンドポートで受信されるすべてのパケットのグローバルカウンタです。

ローカルスイッチまたはポートでBPDUが廃棄されている兆候がない場合は、リンクの反対側のスイッチに移動し、そのスイッチがBPDUを送信するかどうかを確認する必要があります。BPDUがルートではない指定ポートで定期的に送信されているかどうかを確認します。ポートの役割が一致すると、ポートはBPDUを送信しますが、ネイバーはそれを受信しません。BPDUが送信されているかどうかを確認します。次のshow spanning-tree interface interfaceコマンドの詳細を発行します。

cat#show spanning-tree interface g3/1 detail

Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding

Port path cost 20000, Port priority 128, Port Identifier 128.129.

Designated root has priority 0, address 0007.4f1c.e847

Designated bridge has priority 32768, address 00d0.003f.8800

Designated port id is 128.129, designated path cost 2000019

Timers: message age 0, forward delay 0, hold 0

Number of transitions to forwarding state: 0

Link type is point-to-point by default, Internal

Loop guard is enabled by default on the port

BPDU: sent 1774, received 1

cat#show spanning-tree interface g3/1 detail

Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding

Port path cost 20000, Port priority 128, Port Identifier 128.129.

Designated root has priority 0, address 0007.4f1c.e847

Designated bridge has priority 32768, address 00d0.003f.8800

Designated port id is 128.129, designated path cost 2000019

Timers: message age 0, forward delay 0, hold 0

Number of transitions to forwarding state: 0

Link type is point-to-point by default, Internal

Loop guard is enabled by default on the port

BPDU: sent 1776, received 1

この例では、2つのBPDUが出力の間で送信されます。

注:STPプロセスはBPDU:sentcounterを維持します。これは、カウンタがBPDUが物理ポートに向けて送信され、送信されたことを示していることを意味します。送信されたマルチキャストパケットのポートカウンタが増加するかどうかを確認します。show interface interface counterscommandコマンドを発行します。これは、BPDUのトラフィックフローを判別するのに役立ちます。

cat#show interface g3/1 counters

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts

Gi3/1          127985312         83776        812319            19

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts

Gi3/1          131825915          3442        872342           386

cat# show interface g3/1 counters

Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts

Gi3/1          127985312         83776        812319            19

Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts

Gi3/1          131826447          3442        872346           386

これらのすべてのステップを実行すれば、BPDU が受信、送信または処理されなかったスイッチやリンクを発見できます。 STPがポートの正しい状態を計算したが、コントロールプレーンの問題が原因で、転送ハードウェアでこの状態を設定できない可能性があります。ポートがハードウェアレベルでブロックされていない場合は、ループが発生する可能性があります。ご使用のネットワークでこの問題が発生していると考えられる場合は、シスコテクニカルサポートに連絡して、さらにサポートを求めてください。

5.冗長性の復元

ループを引き起こしているデバイスまたはリンクが見つかったら、そのデバイスをネットワークから隔離するか、問題を解決する必要があります（ファイバまたはGBICの交換など）。ステップ 3 で接続解除した冗長リンクを復元する必要があります。

ループを引き起こすデバイスやリンクを操作しないことが重要です。これは、ループを引き起こす多くの条件が一時的、断続的、および不安定であるためです。つまり、調査中または調査後に条件がクリアされた場合、その条件はしばらく発生しないか、まったく発生しません。シスコテクニカルサポートが詳細に調査できるように、この状態を記録する必要があります。スイッチをリセットする前に、このような状況に関する情報を収集することが重要です。状況が解消された場合、ループの根本原因を特定することは不可能です。情報を収集する場合は、この問題によってループが再び発生しないことを確認します。詳細は、『フォワーディングループからネットワークを保護する』を参照してください。

トポロジ変更の調査

トポロジ変更(TC)メカニズムの役割は、トポロジの変更後にL2転送テーブルを修正することです。これは、以前は特定のポートからアクセスできたMACアドレスが、別のポートから変更されてアクセス可能になる可能性があるため、接続不能を回避するために必要です。TCは、TCが発生しているVLAN内のすべてのスイッチで、転送テーブルのエージングを短縮します。そのため、アドレスが再学習されていない場合は、エージングアウトしてフラッディングが発生し、パケットが宛先MACアドレスに確実に到達します。

TCは、ポートのSTPステートがSTPforwardingstateに変更されるか、またはSTPforwardingstateから変更されることによってトリガーされます。TCの発生後は、特定の宛先MACアドレスがエージングアウトしても、フラッディングが長く続くことはありません。このアドレスは、MACアドレスがエージングアウトされたホストからの最初のパケットによって再学習されます。TCが短い間隔で繰り返し発生すると、問題が発生する可能性があります。スイッチは転送テーブルを常にファストエージングしているため、フラッディングはほぼ一定です。

注:Rapid STP(RSTP)またはMultiple STP(MSTP)（IEEE 802.1wおよびIEEE 802.1s）では、ポートの状態がforwardingに変更されたこと、およびロールがfrodesignatedtorootに変更されたことによってTCがトリガーされます。802.1D ではエージング タイムが短縮されるのに対し、Rapid STP では L2 転送テーブルが即座にフラッシュされます。転送テーブルを即時にフラッシュすると、接続の復元は速くなりますが、フラッディングが増加する可能性があります

TCは、適切に設定されたネットワークではまれなイベントです。スイッチポートのリンクがアップまたはダウンすると、ポートのSTP状態がforwardingに変更されるか、fromforwardingから変更されると、最終的にTCが発生します。ポートがフラッピングしていると、TC が繰り返し発生し、そのたびにフラッディングが発生します。

STP PortFast機能が有効になっているポートでは、TCがforwarding状態になった場合やTCが発生した場合に、この障害が発生することはありません。すべてのエンドデバイスポート（プリンタ、PC、サーバなど）でPortFastを設定すると、TCの量が少なくなるため、この設定を行うことを強く推奨します。

ネットワーク上で TC が繰り返し発生する場合は、その TC の発生元を特定し、TC を減らすための処置を行って、フラッディングを最小限に抑える必要があります。

802.1d では、TC イベントに関する STP 情報は、BPDU の特別な種類である TC Notification（TCN; TC 通知）を通じて、各ブリッジに伝搬されます。TCN BPDUを受信するポートをたどると、TCを発信したデバイスを確認できます。

フラッディングの原因の特定

フラッディングは、パフォーマンスの低下が原因であること、輻輳が起こるはずのないリンクでパケットが廃棄されていること、およびローカルセグメント上にない同じ宛先に対する複数のユニキャストパケットがパケットアナライザで示されていることで判断できます。 ユニキャストフラッディングの詳細は、『スイッチドキャンパスネットワークにおけるユニキャストフラッディング』を参照してください。

Cisco IOS ソフトウェアが稼働している Catalyst 6500/6000 では、フォワーディング エンジンのカウンタ（スーパーバイザ 2 エンジンの場合のみ）をチェックして、フラッディングの量を見積ることができます。remote command switch show earl statisticsコマンドを発行します。 | i MISS_DA|ST_FRコマンド：

cat#remote command switch show earl statistics | i MISS_DA|ST_FR

ST_MISS_DA     =       18                      530308834

ST_FRMS        =       97                      969084354

cat#remote command switch show earl statistics | i MISS_DA|ST_FR

ST_MISS_DA     =       4                       530308838

ST_FRMS        =       23                      969084377

この例では、このコマンドが最後に実行されてからの変更が最初のカラムに、最後にリブートしてからの累積値が 2 番目のカラムに示されています。フラッディングが発生したフレームの量が最初の行に示され、処理されたフレームの量が 2 番目の行に示されています。2つの値が近い場合、または最初の値が急速に増加している場合は、スイッチがトラフィックをフラッディングしている可能性があります。ただし、このカウンタは精度が低いので、フラッディングが発生していることを確認するその他の方法と必ず併用するようにしてください。カウンタは、スイッチごとに 1 つ存在します。ポートごとや VLAN ごとではありません。宛先MACアドレスが転送テーブルにない場合はスイッチが常にフラッディングする可能性があるため、一部のフラッディングパケットを確認することは正常です。これは、まだ学習されていない宛先アドレスを持つパケットをスイッチが受信した場合に発生する可能性があります。

TCの発生源の特定

過剰なフラッディングが発生しているVLANのVLAN番号がわかっている場合は、STPカウンタを調べて、TCの数が多いか、定期的に増加しているかを確認します。次のshow spanning-tree vlan vlan-id detailコマンドを発行します（この例では、VLAN 1が使用されています）。

cat#show spanning-tree vlan 1 detail

VLAN0001 is executing the ieee compatible Spanning Tree protocol

Bridge Identifier has priority 32768, sysid 1, address 0007.0e8f.04c0

Configured hello time 2, max age 20, forward delay 15

Current root has priority 0, address 0007.4f1c.e847

Root port is 65 (GigabitEthernet2/1), cost of root path is 119

Topology change flag not set, detected flag not set

Number of topology changes 1 last change occurred 00:00:35 ago

from GigabitEthernet1/1

Times:  hold 1, topology change 35, notification 2

hello 2, max age 20, forward delay 15

Timers: hello 0, topology change 0, notification 0, aging 300

VLAN 番号がわからない場合は、パケット アナライザを使用するか、またはすべての VLAN の TC カウンタをチェックします。

過度の TC を防ぐための処置

Number of topologyの変更カウンタをモニタして、定期的に増加するかどうかを確認できます。次に、最後の TC を受信したポート（前の例では、GigabitEthernet 1/1 というポート）に接続されているブリッジに移動し、そのブリッジへの TC がどこから来たかを調べます。STP PortFast が有効になっていない端末ポートが見つかるか、修正が必要なフラッピング リンクが見つかるまで、この処理を繰り返す必要があります。TCが他の発生源から発生する場合は、手順全体を繰り返す必要があります。リンクがエンドホストに属している場合は、PortFast機能を設定してTCの発生を防止できます。

注:Cisco IOSソフトウェアのSTP実装では、TCN BPDUがVLANのポートで受信された場合にのみ、TCのカウンタが増加します。TCフラグが設定された通常のコンフィギュレーションBPDUが受信されても、TCカウンタは増分されません。つまり、フラッディングの原因がTCであると疑われる場合は、そのVLANのSTPルートブリッジからTCの発生源を突き止めます。TCの数と発生源に関して最も正確な情報を得ることができます。

コンバージェンス時間関連の問題のトラブルシューティング

STP の実際の動作が、期待した動作とは異なる場合があります。最もよく発生する 2 つの問題は、次のとおりです。

- STP コンバージェンスまたは再コンバージェンスに、予想以上に時間がかかる。

- トポロジ結果が予想と異なる。

多くの場合、このような動作は次の原因で発生します。

- 実際のトポロジと文書に記載されているトポロジのミスマッチ.

- STPタイマーの設定の不整合、STPの直径の増加、PortFastの設定ミスなどの設定ミス。

- コンバージェンス時または再コンバージェンス時にスイッチの CPU に過負荷がかかっている.

- ソフトウェアの欠陥.

前述のとおり、STP に影響を与える問題は多岐に渡るので、このドキュメントでは、トラブルシューティングの一般的なガイドラインだけを説明します。 コンバージェンスに予想以上に時間がかかる理由を理解するには、STPイベントのシーケンスを調べて、何が起こっているか、どのような順序で行われているかを調べます。Cisco IOSソフトウェアのSTP実装は結果をログに記録しないため（ポートの不一致などの特定のイベントを除く）、Cisco IOSソフトウェアを使用してSTPをデバッグすると、より明確な情報を得ることができます。 Cisco IOS ソフトウェアが稼働している Catalyst 6500/6000 で STP を使用する場合は、Switch Processor（SP; スイッチ プロセッサ）（またはスーパーバイザ）で処理が行われます。したがって、SP でデバッグを有効にする必要があります。Cisco IOSソフトウェアのブリッジグループの場合、処理はルートプロセッサ(RP)で実行されるため、デバッグはRP(MSFC)で有効にする必要があります。

STP debugコマンドの使用

多くのSTPdebugcommandsは、開発技術者向けです。その出力を理解するには、Cisco IOS ソフトウェアの STP の実装に関する詳細な知識が必要になります。いくつかのデバッグは、すぐに読める形で出力できます。これには、ポートの状態や役割の変化、TC などのイベント、受信または送信された BPDU のダンプなどが含まれます。このセクションでは、すべてのデバッグを詳細に説明することはせず、最もよく使用されるデバッグを簡単に説明します。

注：debugコマンドを使用する場合、必要最小限のデバッグを有効にします。リアルタイムでデバッグを行う必要がない場合は、出力はコンソールに表示させず、ログに記録するようにしてください。過度のデバッグを行うと、CPU に過負荷がかかり、スイッチの動作が中断する場合があります。

デバッグ出力をコンソールやTelnetセッションに送るのではなく、ログに送るには、グローバルコンフィギュレーションモードでconsole informationおよびno logging monitorcommandsコマンドをロギングします。 一般的なイベントログを表示するには、Per VLAN Spanning-Tree(PVST)とRapid-PVSTに対してdebug spanning-tree eventcommandを発行します。これは、STPで何が起こったかに関する情報を提供する最初のデバッグです。 Multiple Spanning-Tree（MST；多重スパニングツリー）モードでは、debug spanning-tree eventcommandを発行できません。したがって、debug spanning-tree mstp rolescommandコマンドを発行して、ポートの役割の変更を確認します。 ポートのSTP状態の変化を確認するには、debug spanning-tree switch statecommandとdebug pm vpcommandを発行します。

cat-sp#debug spanning-tree switch state

Spanning Tree Port state changes debugging is on

cat-sp#debug pm vp

Virtual port events debugging is on

Nov 19 14:03:37: SP:     pm_vp 3/1(333): during state forwarding, got event 4(remove)

Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333):

forwarding -> notforwarding

port 3/1 (was forwarding) goes down in vlan 333

Nov 19 14:03:37: SP: *** vp_fwdchange: single: notfwd: 3/1(333)

Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): notforwarding -> present

Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/1(333)

Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): present -> not_present

Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/1(333)

Nov 19 14:03:37: SP:     pm_vp 3/2(333): during state notforwarding,

got event 4(remove)

Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): notforwarding -> present

Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/2(333)

Port 3/2 (was not forwarding) in vlan 333 goes down

Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): present -> not_present

Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/2(333)

Nov 19 14:03:53: SP:     pm_vp 3/1(333): during state not_present,

got event 0(add)

Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): not_present -> present

Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/1(333)

Nov 19 14:03:53: SP:     pm_vp 3/1(333): during state present,

got event 8(linkup)

Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): present ->

notforwarding

Nov 19 14:03:53: SP: STP SW: Gi3/1 new blocking req for 0 vlans

Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/1(333)

Port 3/1 link goes up and blocking in vlan 333

Nov 19 14:03:53: SP:     pm_vp 3/2(333): during state not_present,

got event 0(add)

Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): not_present -> present

Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/2(333)

Nov 19 14:03:53: SP:     pm_vp 3/2(333): during state present,

got event 8(linkup)

Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): present ->

notforwarding

Nov 19 14:03:53: SP: STP SW: Gi3/2 new blocking req for 0 vlans

Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/2(333)

Port 3/2 goes up and blocking in vlan 333

Nov 19 14:04:08: SP: STP SW: Gi3/1 new learning req for 1 vlans

Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 0 vlans

Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 1 vlans

Nov 19 14:04:23: SP:     pm_vp 3/1(333): during state notforwarding,

got event 14(forward_notnotify)

Nov 19 14:04:23: SP: @@@ pm_vp 3/1(333): notforwarding ->

forwarding

Nov 19 14:04:23: SP: *** vp_list_fwdchange: forward: 3/1(333)

Port 3/1 goes via learning to forwarding in vlan 333

STP が特定の動作を行う理由を調べる場合には、スイッチが受信または送信した BPDU を見ると、多くの場合役に立ちます。

cat-sp#debug spanning-tree bpdu receive

Spanning Tree BPDU Received debugging is on

Nov  6 11:44:27: SP: STP: VLAN1 rx BPDU: config protocol = ieee,

packet from GigabitEthernet2/1  , linktype IEEE_SPANNING ,

enctype 2, encsize 17

Nov  6 11:44:27: SP: STP: enc 01 80 C2 00 00 00 00 06 52 5F 0E 50 00 26 42 42 03

Nov  6 11:44:27: SP: STP: Data 0000000000000000074F1CE8470000001380480006525F0E4

080100100140002000F00

Nov  6 11:44:27: SP: STP: VLAN1 Gi2/1:0000 00 00 00 000000074F1CE847 00000013

80480006525F0E40 8010 0100 1400 0200 0F00

このデバッグはPVST、Rapid-PVST、およびMSTモードで機能しますが、BPDUの内容はデコードされません。しかし、BPDU が受信されていることは確認できます。 BPDUの内容を表示するには、PVSTおよびRapid-PVSTに対してdebug spanning-tree switch rx processcommandと共にdebug spanning-tree switch rx decodecommandを発行します。MSTのBPDUの内容を確認するには、debug spanning-tree mstp bpdu-rxcommandコマンドを発行します。

cat-sp#debug spanning-tree switch rx decode

Spanning Tree Switch Shim decode received packets debugging is on

cat-sp#debug spanning-tree switch rx process

Spanning Tree Switch Shim process receive bpdu debugging is on

Nov  6 12:23:20: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026

Nov  6 12:23:20: SP:     encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1

Nov  6 12:23:20: SP:     42 42 03 SPAN

Nov  6 12:23:20: SP:     CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013

Nov  6 12:23:20: SP:     B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00

Nov  6 12:23:22: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026

Nov  6 12:23:22: SP:     encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1

Nov  6 12:23:22: SP:     42 42 03 SPAN

Nov  6 12:23:22: SP:     CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013

Nov  6 12:23:22: SP:     B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00

MSTモードでは、次のdebugコマンドを使用して詳細なBPDUのデコードを有効にできます。

cat-sp#debug spanning-tree mstp bpdu-rx

Multiple Spanning Tree Received BPDUs debugging is on

Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated]

Nov 19 14:37:43: SP: MST:   Proto:0 Version:3 Type:2 Role: DesgFlags[   F    ]

Nov 19 14:37:43: SP: MST:   Port_id:32897 cost:2000019

Nov 19 14:37:43: SP: MST:   root_id  :0007.4f1c.e847 Prio:0

Nov 19 14:37:43: SP: MST:   br_id    :00d0.003f.8800 Prio:32768

Nov 19 14:37:43: SP: MST:   age:2 max_age:20 hello:2 fwdelay:15

Nov 19 14:37:43: SP: MST:   V3_len:90 PathCost:30000 region:STATIC rev:1

Nov 19 14:37:43: SP: MST:   ist_m_id :0005.74

Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated]

Nov 19 14:37:43: SP: MST:   Proto:0 Version:3 Type:2 Role: DesgFlags[   F    ]

Nov 19 14:37:43: SP: MST:   Port_id:32897 cost:2000019

Nov 19 14:37:43: SP: MST:   root_id  :0007.4f1c.e847 Prio:0

Nov 19 14:37:43: SP: MST:   br_id    :00d0.003f.8800 Prio:32768

Nov 19 14:37:43: SP: MST:   age:2 max_age:20 hello:2 fwdelay:15

Nov 19 14:37:43: SP: MST:   V3_len:90 PathCost:30000 region:STATIC rev:1

Nov 19 14:37:43: SP: MST:   ist_m_id :0005.7428.1440 Prio:32768  Hops:18

Num Mrec: 1

Nov 19 14:37:43: SP: MST: stci=3  Flags[ F    ] Hop:19 Role:Desg [Repeated]

Nov 19 14:37:43: SP: MST:         br_id:00d0.003f.8800 Prio:32771 Port_id:32897

Cost:2000028.1440 Prio:32768  Hops:18  Num Mrec: 1

Nov 19 14:37:43: SP: MST: stci=3  Flags[ F    ] Hop:19 Role:Desg [Repeated]

Nov 19 14:37:43: SP: MST:         br_id:00d0.003f.8800 Prio:32771 Port_id:32897

Cost:20000

注:Cisco IOSソフトウェアリリース12.1.13E以降では、STPの条件付きデバッグがサポートされています。これにより、受信または送信された BPDU をポートごとまたは VLAN ごとにデバッグできます。

debug condition vlan vlan_num またはdebug condition interface interface コマンドを発行して、デバッグ出力の範囲をインターフェイスごとまたはVLANごとに制限します。

フォワーディングループからのネットワークの保護

シスコでは、STPで特定の障害を管理できない場合にフォワーディングループからネットワークを保護するために、多くの機能と拡張機能を開発しました。

STPのトラブルシューティングを行う際には、特定の障害の原因を切り分け、場合によっては見つけるのに役立ちますが、フォワーディングループからネットワークを保護するには、これらの機能拡張を実装することが唯一の方法です。

次に、フォワーディング ループからネットワークを保護する方法を示します。

1.すべてのスイッチ間リンクで単方向リンク検出(UDLD)を有効にする

UDLDの詳細については、『単方向リンク検出プロトコル機能の説明と設定』を参照してください。

2.すべてのスイッチでループガードを有効にする

ループガードの詳細については、『ループガードとBPDUスキュー検出機能によるスパニングツリープロトコルの拡張機能』を参照してください。

UDLDとループガードを有効にすると、フォワーディングループの原因の大部分が排除されます。フォワーディングループが発生する代わりに、障害のあるリンク（または障害のあるハードウェアに依存するすべてのリンク）がシャットダウンまたはブロックされます。

注：この2つの機能は若干冗長に見えますが、それぞれ固有の機能を備えています。したがって、両方の機能を同時に使用すれば、最も高度な保護が行われます。UDLDとループガードの詳細な比較については、『ループガードと単方向リンク検出』を参照してください。

アグレッシブ UDLD を使用すべきか、通常の UDLD を使用すべきかについては、さまざまな意見があります。アグレッシブUDLDでは、通常モードのUDLDに比べて、ループに対する保護を強化できません。アグレッシブ UDLD では、ポートスタックのシナリオ（リンクはアップ状態だが、関連するトラフィックのブラックホールがない状態）が検出されます。この追加機能の欠点は、一貫した障害が存在しないと、アグレッシブ UDLD によってリンクが無効にされてしまう可能性があることです。UDLDhellointervalの変更は、アグレッシブUDLD機能と混同されることがよくあります。これは正しくありません。タイマーは、どちらの UDLD モードでも修正できます。

注：まれに、アグレッシブUDLDによってすべてのアップリンクポートがシャットダウンされ、スイッチがネットワークの他の部分から切り離されることがあります。たとえば、両方のアップストリームスイッチでCPU使用率が極端に高くなり、アグレッシブモードのUDLDが使用されている場合に、この状態が発生する可能性があります。したがって、スイッチにアウトオブバンド管理が設定されていない場合は、エロードできないタイムアウトを設定することを推奨します。

3.すべてのエンドステーションポートでPortFastを有効にする

ネットワークのパフォーマンスに影響を与える可能性のある TC およびそれに続くフラッディングの量を制限するためには、PortFast を有効にする必要があります。このコマンドは、エンドステーションに接続するポートでのみ使用します。そうしないと、予期しないトポロジループが原因でデータパケットループが発生し、スイッチとネットワークの動作が中断する可能性があります。

注意:no spanning-tree portfastコマンドを使用する場合は注意が必要です。このコマンドで削除されるのは、ポート固有のPortFastコマンドだけです。このコマンドは、グローバルコンフィギュレーションモードでspanning-tree portfast defaultコマンドを定義した場合、およびポートがトランクポートでない場合に、PortFastを暗黙的に有効にします。PortFastをグローバルに設定しない場合、no spanning-tree portfastコマンドはspanning-tree portfast disableコマンドと同じになります。

4.両側（サポートされている場合）でEtherChannelをDesirableモードに設定し、Non-Silentオプションを設定する

Desirableモードでは、ポート集約プロトコル(PAgP)を有効にして、チャネリングピア間でランタイムの一貫性を確保できます。これによって、特にチャネルの再設定時（チャネルへのリンクの追加時や削除時、リンク障害の検出時など）に、ループの発生を防止する能力が一段と強化されます。チャネル設定ミスガードが組み込まれています。このガードはデフォルトで有効になっており、チャネルの設定ミスやその他の状況によるフォワーディングループを防止します。この機能の詳細については、『EtherChannelの不一致検出について』を参照してください。

5.スイッチ間リンクでオートネゴシエーションを無効にしない（サポートされている場合）

自動ネゴシエーション メカニズムは、リモート障害情報を伝達できます。これは、リモート側での障害を最も早く検出できる方法です。リモート側で障害が検出されると、リンクにパルスが送られても、ローカル側がリンクをダウンさせます。UDLDなどの高レベルの検出メカニズムと比較すると、自動ネゴシエーションは（マイクロ秒以内で）非常に高速ですが、UDLDのエンドツーエンドのカバレッジは存在しません（データパス：CPU – 転送ロジック – ポート1 – ポート2 – 転送ロジック – CPU対ポート1 – ポート2など）。障害検出機能については、アグレッシブ UDLD モードの機能と自動ネゴシエーションの機能はよく似ています。リンクの両端でネゴシエーションがサポートされている場合には、アグレッシブモードの UDLD を有効にする必要はありません。

6. STPタイマーを調整する際には注意が必要です

STP タイマーは、タイマー相互およびネットワーク トポロジに依存しています。タイマーに対して任意の変更を加えても、STPが正しく動作しない。STPタイマーの詳細については、『スパニングツリープロトコル(STP)タイマーの説明と調整』を参照してください。

7.サービス拒絶攻撃を受ける可能性がある場合は、ルートガードを使用してネットワークSTP境界を保護します

ルート ガードと BPDU ガードを使用すると、外部の操作から STP を保護できます。このような攻撃を受ける可能性がある場合には、ルート ガードと BPDU ガードを使用してネットワークを保護する必要があります。ルート ガードおよび BPDU ガードの詳細は、次のドキュメントを参照してください。

- スパニングツリー プロトコル ルート ガード機能拡張

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

8. PortFast対応ポートでBPDUガードを有効にして、ポートに接続された不正なネットワークデバイス（ハブ、スイッチ、ブリッジングルータなど）によるSTPの影響を防止します

ルートガードを正しく設定すると、外部からのSTPの影響を受けなくなります。BPDUガードが有効になっている場合は、BPDUを受信するポートがシャットダウンされます。BPDUガードはsyslogメッセージを生成してポートをシャットダウンするため、これはインシデントの調査に役立ちます。ルートガードまたはBPDUガードによってショートサイクルループが防止されない場合は、2つの高速対応ポートが直接またはハブを介して接続されます。

9.管理VLANでのユーザトラフィックの回避

管理 VLAN は、ネットワーク全体ではなく、ビルディング ブロックに限定します。

管理 VLAN のブロードキャスト パケットは、スイッチ管理インターフェイスで受信されます。過剰なブロードキャスト（ブロードキャストストームやアプリケーションの動作不良など）が発生すると、スイッチのCPUが過負荷になり、STPの動作が歪む可能性があります。

10.予測可能な（ハードコードされた）STPルートとバックアップSTPルートの配置

STP ルートとバックアップ STP ルートを設定して、どのような状況で障害が発生してもコンバージェンスが予測どおりに行われ、トポロジが適切に構築されるようにしておく必要があります。STP の優先順位をデフォルト値のままにして、どのルート スイッチが選択されるか予測できない状態にはしないでください。

関連情報

- LAN 製品に関するサポート ページ

- LAN スイッチングに関するサポート ページ