(モデレーターの要求によりNEngからSFに移動)
Debian 10、Linuxカーネル4.19の上にいくつかのスイッチ管理ソフトウェアを開発しています。 Linuxブリッジ(switchdevを介して独自のハードウェアにオフロード)を使用して、レイヤー2スイッチングを行っています。私を混乱させるいくつかのことがあります:
多くの読書といくつかの実験の後に私の質問への答えを見つけました。正確に何を検索すればよいのかを知らずに答えを見つけるのは難しいため、同様の問題が発生した場合に備えて、ここで要約します。
コンテキストについては、以前のレイヤー2スイッチングとVLANの実装は、Cumulus Linuxの Traditional Linux Bridge Mode と同じです。 VLANごとにブリッジが作成されます。トランクポートは、VLANタグ付きサブインターフェイスを追加することで実装され、それらの各サブインターフェイスは、トランクアクセスリストの対応するVLANに追加されます。いくつかの設定例については、Cumulusユーザーガイドページを参照してください。
質問2に答えるには、いいえ。LinuxSTPインスタンスをVLANごとにオンにしても、このPVST +またはPVST +との互換性はありません。 PVST +には、VLANタグ付きBPDUパケットの送信以上のものが含まれます。宛先MACアドレスが異なり、SNAPヘッダーが存在し、VLAN情報を運ぶフィールドがペイロードに追加されます。反対側のシスコスイッチは、VLANタグ付きの802.1d BPDUパケットを受け入れません。また、PVST +が802.1を送信するトランクポートのネイティブVLAN以外のVLANも受け入れません。 d下位互換性のためにVLAN 1トポロジに対応するBPDUは、任意のBPDUを受信します。まったく機能しません。
現在の実装では、3.9以降のメインラインLinuxで使用可能なVLAN対応ブリッジを使用しています。 STPの単一インスタンスがすべてのVLANに対して実行されます。これはMSTPと相互運用可能です。概念的には、すべてのVLANを1つのMSTインスタンスにマッピングしてMSTPを実行しているかのようです。したがって、質問1に答えるために、LinuxはMSTPを実行しませんが、STP + VLAN対応のブリッジはMSTPと相互運用できます。
編集:CumulusがPVST +をどのように実行するのか疑問に思われるかもしれません。その答えは、PVST +を独自に実装したパッチを適用したカーネルを実行することです。また、避けるべき大きな落とし穴: [〜#〜] mstpd [〜#〜] は、その主張にもかかわらずPVST +を実行しません。 PVST +サポートのために拡張することを検討しています。