Catalystスイッチでの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
現在のトラフィックレベルが過剰であるか、またはベースラインレベルが不明な場合は、最近ピークレベルに達したかどうかと、ピークレベルが現在のトラフィックレベルに近いかどうかを確認します。たとえば、ピーク時のトラフィックレベルが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.ループの解除
ループを遮断するには、関係するポートをシャットダウンするか接続解除します。ループを停止するだけでなく、ループの根本原因を見つけて修正することも特に重要です。ループを切断する方が比較的簡単です
次のトポロジ例では、ループはスイッチ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
表示されるカウンタは、STP プロセスによって実際に維持されるカウンタです。これは、受信カウンタが増加した場合、BPDUが物理ポートで受信されただけでなく、STPプロセスでも受信されたことを意味します。 If the received 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 個のパケットがインバンド ポートにより受信されたことを示しています。
ローカルスイッチまたはポートで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が出力の間で送信されます。
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が短い間隔で繰り返し発生すると、問題が発生する可能性があります。スイッチは転送テーブルを常にファストエージングしているため、フラッディングはほぼ一定です。
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の発生を防止できます。
コンバージェンス時間関連の問題のトラブルシューティング
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 のダンプなどが含まれます。このセクションでは、すべてのデバッグを詳細に説明することはせず、最もよく使用されるデバッグを簡単に説明します。
デバッグ出力をコンソールや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
debug condition vlan vlan_num またはdebug condition interface interface コマンドを発行して、デバッグ出力の範囲をインターフェイスごとまたはVLANごとに制限します。
フォワーディングループからのネットワークの保護
シスコでは、STPで特定の障害を管理できない場合にフォワーディングループからネットワークを保護するために、多くの機能と拡張機能を開発しました。
STPのトラブルシューティングを行う際には、特定の障害の原因を切り分け、場合によっては見つけるのに役立ちますが、フォワーディングループからネットワークを保護するには、これらの機能拡張を実装することが唯一の方法です。
次に、フォワーディング ループからネットワークを保護する方法を示します。
1.すべてのスイッチ間リンクで単方向リンク検出(UDLD)を有効にする
UDLDの詳細については、『単方向リンク検出プロトコル機能の説明と設定』を参照してください。
2.すべてのスイッチでループガードを有効にする
ループガードの詳細については、『ループガードとBPDUスキュー検出機能によるスパニングツリープロトコルの拡張機能』を参照してください。
UDLDとループガードを有効にすると、フォワーディングループの原因の大部分が排除されます。フォワーディングループが発生する代わりに、障害のあるリンク（または障害のあるハードウェアに依存するすべてのリンク）がシャットダウンまたはブロックされます。
アグレッシブ UDLD を使用すべきか、通常の UDLD を使用すべきかについては、さまざまな意見があります。アグレッシブUDLDでは、通常モードのUDLDに比べて、ループに対する保護を強化できません。アグレッシブ UDLD では、ポートスタックのシナリオ（リンクはアップ状態だが、関連するトラフィックのブラックホールがない状態）が検出されます。この追加機能の欠点は、一貫した障害が存在しないと、アグレッシブ UDLD によってリンクが無効にされてしまう可能性があることです。UDLDhellointervalの変更は、アグレッシブUDLD機能と混同されることがよくあります。これは正しくありません。タイマーは、どちらの UDLD モードでも修正できます。
3.すべてのエンドステーションポートでPortFastを有効にする
ネットワークのパフォーマンスに影響を与える可能性のある TC およびそれに続くフラッディングの量を制限するためには、PortFast を有効にする必要があります。このコマンドは、エンドステーションに接続するポートでのみ使用します。そうしないと、予期しないトポロジループが原因でデータパケットループが発生し、スイッチとネットワークの動作が中断する可能性があります。
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 ガードの詳細は、次のドキュメントを参照してください。
8. PortFast対応ポートでBPDUガードを有効にして、ポートに接続された不正なネットワークデバイス（ハブ、スイッチ、ブリッジングルータなど）によるSTPの影響を防止します
ルートガードを正しく設定すると、外部からのSTPの影響を受けなくなります。BPDUガードが有効になっている場合は、BPDUを受信するポートがシャットダウンされます。BPDUガードはsyslogメッセージを生成してポートをシャットダウンするため、これはインシデントの調査に役立ちます。ルートガードまたはBPDUガードによってショートサイクルループが防止されない場合は、2つの高速対応ポートが直接またはハブを介して接続されます。
9.管理VLANでのユーザトラフィックの回避
管理 VLAN は、ネットワーク全体ではなく、ビルディング ブロックに限定します。
管理 VLAN のブロードキャスト パケットは、スイッチ管理インターフェイスで受信されます。過剰なブロードキャスト（ブロードキャストストームやアプリケーションの動作不良など）が発生すると、スイッチのCPUが過負荷になり、STPの動作が歪む可能性があります。
10.予測可能な（ハードコードされた）STPルートとバックアップSTPルートの配置
STP ルートとバックアップ STP ルートを設定して、どのような状況で障害が発生してもコンバージェンスが予測どおりに行われ、トポロジが適切に構築されるようにしておく必要があります。STP の優先順位をデフォルト値のままにして、どのルート スイッチが選択されるか予測できない状態にはしないでください。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
18-Jul-2023 |
概要、SEO、ブランディング要件、機械翻訳、スタイル要件、およびフォーマットを更新。 |
2.0 |
28-Jun-2022 |
再教育用および外部用の文書に対してのみ書式を変更します。 |
1.0 |
19-Nov-2002 |
初版 |
フィードバック