매립형 스위치가 포함된 보드가 있습니다. 이러한 장치는 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에 대해 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이 연속성 메시지만 처리하도록 일부 필터링을 사용하여).