埋め込み型スイッチを含むボードがあります。これらのデバイスはERPS（https://en.wikipedia.org/wiki/Ethernet_Ring_Protection_Switching）セットアップを実行すると、補助装置（ノートブック、ディスプレイ装置など）をスイッチの残りのポートに接続することもできます。
以前は、これらのデバイスは、スイッチをサポートするために広範囲のツリー外部パッチを含むLinuxカーネルを使用していました。今私たちはswitchdevフレームワークを使用しようとしています。つまり、ブリッジを作成してVLANメンバーシップなどを処理するコマンドをip使用します。bridgeただし、ERPSロジックは依然として特定のポートでパケットを送受信できる必要があります。たとえば、リングのリンクが切断され、冗長リンクがブロック解除されなければならない時期を知るためにはまだ必要です。
LLDPを使用して、リングプロトコルの一部であるデバイスで構成されたネイバーとセカンダリデバイスであるネイバーを理解します。これは、VLAN メンバーシップルールにも重要です。
したがって、次のコマンドを使用して、ポートlan1、lan2、lan3、lan4、およびブリッジ（lanx）が作成されました。
ip link add name lanx type bridge vlan_default_pvid 0
ip link set dev lan1 master lanx
...
ip link set dev lan4 master lanx
bridge vlan add dev lanx vid 1 self
bridge vlan add dev lanx vid 3 self
ip link add link lanx name lanx.1 type vlan id 1
ip link add link lanx name lanx.3 type vlan id 3
ERPSを実装するために、lan1、...、lan4ごとに3つのVLANのサブインターフェイスがあります。
ip link add link lan1 name lan1.3 type vlan id 3
...
すべてのポートはvlan1のメンバーである必要があり、スイッチを介して他のデバイスに接続されているポートのみがvlan3のメンバーである必要があります。 LLDP は、そのようなネイバー 1 つまたは 2 つのネイバーを検出すると、lan1.3 および lan3.3 で erps インスタンスを起動します。
すべてがうまくいきます。すべてのデバイスが連携して1つのポートのみをブロックします。ケーブルを抜くと、デバイスはポートのロックを解除し、トラフィックが流れ続ける可能性があります。 VLAN1 のトラフィックです。 VLAN3 トラフィックがまったく機能しないようです。 「ping $ip%lanx.3」を使用して他のデバイスのIPv6LLアドレスをpingすると失敗しますが、「ping $ip%lanx.1」は正常に動作します。これはおそらく驚くべきことではありません。 tcpdumpは、pingが他のデバイスのlan1.3（lanx.3ではない）に達し、そのデバイスが応答し、応答が最初のデバイスのlan2.3に行ったことを示すようです。実際、「ping $ip%lan2.3」はうまくいくようです。そして、我々は、erpsロジックがこれらのlanN.3サブデバイスで正しく通信していることをすでに知っています。
したがって、lan1.3サブデバイスを削除し、erpsプログラムがlanx.3を使用するようにアクティブにする必要がありますが、連続性メッセージが特定のポートで送信（および受信）されるようにする必要があります。これは可能ですか？あるいは、lan1から受信したすべてのvlan3トラフィックをlan1.3に送信するのではなく、ブリッジデバイスに到達するようにカーネルに指示する必要があります（好ましくは、lan1.3が連続メッセージのみを処理するようにいくつかのフィルタリングを使用して）。