コンバージェンス中のパケット損失を防ぐためにスパニングツリーの変更を予測するにはどうすればよいですか？
Ciscoスイッチ、冗長ケーブル、スパニングツリーを備えたLANがあります。正しく理解していれば、冗長ケーブル（現在スパニングツリーで「使用」されている）を引き出すと、スパニングツリーが反応して収束するまでに数秒かかります。このパケット損失を防ぐにはどうすればよいですか（もちろん、ケーブルが引っ張られることが事前にわかっていると仮定します）。つまり、スパニングツリーを「プロアクティブに」適応させるにはどうすればよいでしょうか。
インターフェースshutdownに加えて数秒待つだけで十分だと思いましたが、まだ試してみませんでした。実際、昨日、一部のインターフェイスで無害と思われる構成変更を行ったときにこのような中断が発生したため、インターフェイスのシャットダウンによってコンバージェンス中に同じ中断時間が発生するのではないかと心配しています。 （編集：これを実験的に確認しました。予想どおり、インターフェイスのシャットダウン後に約20秒の中断がありました-「ロスレス」だけでなく、「ロスレス」ソリューションを探していることに注意してください）
高速STPの代わりにクラスSTP）を使用しているようです。2つのオプションを使用すると、収束時間が大幅に短縮されます。
interface *server interface*
spanning-tree portfast
これはサーバーインターフェイスに適用する必要があります。 STPこのポートの反対側にはスイッチがなく、ループを防ぐ通常の「安全な」方法をスキップしても安全であることがわかります。ポートは転送に直接移動する必要があります。 。
spanning-tree mode rapid-pvst
新しいRapidPer-VLAN Spanning Treeプロトコルを有効にします。これは、スイッチ間のメッセージを使用して、30〜45秒ではなく数秒以内に再コンバージェンスを有効にします。
冗長な単一リンクの代わりに、スイッチ間にポートチャネルを設定してみてください。これにより、1つが失われた場合に、すべてのトラフィックを残りのポートにフェイルオーバーできます。
ケラーが言うように、エッジポートに面するポートファストを確実に有効にしますが、それはここで心配していることではありません。
従来のスパニングツリーを実行している場合は、高速に移行すると停止時間が短縮されます。クラシックからラピッドに移行するときは、再収束する可能性があることに注意してください。ただし、通常はありません。
あなたが探しているのは スパニングツリーコスト### コマンドです。サービスを停止するリンクを冗長リンクよりも高いコストにする必要があります。スパニングツリーはそのリンクをブロックし、他のリンクのブロックを解除します。または、ネットワークレイアウトに応じて、ループ回避や停止回復のためにスパニングツリーに依存しない非ループVLANを実行できます。
そして、編集して追加します...メンテナンス後にスパニングツリーコスト設定を削除し、リンクがバックアップされることを忘れないでください。これにより、ネットワークは当初の設計どおりに実行されます。