我们有一块包含嵌入式开关的板。这些设备应该用于 ERPS（https://en.wikipedia.org/wiki/Ethernet_Ring_Protection_Switching）设置，同时还允许将辅助设备（例如笔记本电脑、显示装置等）连接到交换机上的其余端口。
此前，这些设备使用带有大量树外补丁的 Linux 内核来支持交换机。现在，我们尝试使用 switchdev 框架，即创建一个网桥并使用ip和bridge命令来处理 vlan 成员资格等。但是，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的vlan 3个子接口：
ip link add link lan1 name lan1.3 type vlan id 3
...
所有端口都应该是 vlan1 的成员，而只有通过交换机连接到其他设备的端口才是 vlan3 的成员。当 LLDP 发现这样的邻居或两个邻居时，会在 lan1.3 和 lan3.3 上启动 erps 实例。
一切都运转良好；所有设备协同工作，阻塞一个且仅一个端口；拔掉电缆，设备就会解锁该端口，以便流量继续流动。即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 只处理连续性消息）。