브리지 트래픽이 일부 포트에 도달하지 않습니다.

브리지 트래픽이 일부 포트에 도달하지 않습니다.

L2TPv3을 통해 두 호스트 사이에 터널이 있습니다. 터널의 각 끝은 다른 인터페이스와 마찬가지로 브리지에 속합니다. 원격 브리지에는 추가 DHCP 서버가 있고 로컬 브리지에는 DHCP 클라이언트가 있습니다. 이를 테스트하기 위해 호스트 시스템에 veth 쌍을 만들었습니다. 절반은 브리지에 종속시키고 나머지 절반은 새 네트워크 네임스페이스에 넣었습니다. 그런 다음 네임스페이스의 나머지 절반에서 DHCP 클라이언트를 시작합니다. 이와 같이:

ip netns add test
ip link add test1 type veth peer test2
ip link set test2 netns test up
ip link set test1 master tunnel_bridge up
ip netns exec test dhclient -d test2

이는 모두 예상대로 작동합니다. test2 인터페이스에 대한 DHCP 임대가 얻어지고 구성됩니다. Tunnel_bridge 인터페이스에서 이미 실행 중인 DHCP 클라이언트도 주소를 얻습니다.

이제 L2TPv3 터널을 VxLAN 터널로 교체하려고 합니다. VxLAN에 피어가 두 개만 있어야 할 이유는 없지만 이 경우에는 있습니다. VxLAN은 정적 플러딩이 포함된 유니캐스트로 구성됩니다.

이제 브리지 간의 트래픽이 양호합니다. 로컬 브리지는 DHCP를 통해 주소를 얻을 수 있고 원격 브리지를 ping할 수 있습니다. 그러나 DHCP 서버의 DHCP 응답은 로컬 브리지에서 슬레이브 인터페이스로 전파되지 않습니다. 브리지에 이더넷 포트, veth 인터페이스 및 WiFi AP를 추가해 보았습니다. 각 경우에 tcpdump는 DHCP 요청이 로컬 브리지로 이동하고 터널을 통해 원격 브리지로 이동하며 응답이 터널을 통해 로컬 브리지에 도달하지만 요청이 이루어진 인터페이스에는 도달하지 않음을 보여줍니다.

두 브릿지 모두 STP가 켜져 있습니다(그러나 끄는 것도 시도해 보았습니다). /sys/class/net/tunnel_bridge/bridge/nf_call_arptables그리고 /sys/class/net/tunnel_bridge/bridge/nf_call_iptables둘 다 0. 모든 iptable은 비어 있고 기본 정책은 로 설정되어 있습니다 ACCEPT. 모든 ebtable이 비어 있습니다. brctl showstp모든 포트가 전달 상태에 있음을 표시합니다.

내가 아는 한,오직작동하는 구성과 작동하지 않는 구성의 차이점은 L2TPv3 터널을 VxLAN 터널로 대체한다는 것입니다. 이는 트래픽이 브리지에서 다른 인터페이스로 전파되는 방식에 어떤 영향을 줍니까? 또 무엇을 확인할 수 있나요?

편집하다여기서 대답의 일부는 VxLAN이 터널에 도착하는 패킷을 원래 브리지로 다시 에코한다는 것입니다. 그래서 원래 DHCP 요청이 브리지에 도착하여 터널로 들어간 다음 브리지에 도착하는 중복 프레임을 봅니다. 이로 인해 브리지는 MAC 주소를 찾을 수 있는 포트에 대한 아이디어를 업데이트하게 되며, 이는 응답이 요청이 이루어진 포트가 아닌 VxLAN 터널로 다시 전달된다는 것을 의미합니다. 설정 brctl setageing tunnel_bridge 0으로 인해 브리지가 모든 패킷을 모든 브리지 포트로 플러딩한 다음 "작동"합니다. 그러나 이는 확실히 이상적인 것은 아닙니다. VxLAN 터널이 이 작업을 수행하고 있다는 직접적인 증거는 없지만 VxLAN이 L2TPv3으로 교체되면 모든 것이 잘 작동한다는 것뿐입니다. VxLAN 터널링이 왜 이렇게 하는지 잘 모르겠습니다.

답변1

여기서 문제는 실제로 VxLAN 문제입니다. VxLAN 터널의 원격 측에 있는 fdb에 브로드캐스트 항목을 추가하는 자동 프로세스가 있습니다(예 bridge fdb append 00:00:00:00:00:00 dst <remote ip> dev vxlan1: 이 프로세스도 잘못 추가됨).현지의VxLAN 끝점 역할을 하는 IP 주소입니다.

따라서 veth 인터페이스에서 DHCP 요청이 전송되면 veth 인터페이스의 MAC 주소(DHCP 프레임의 소스 MAC)에 대한 유니캐스트 fdb 항목이 브리지의 포트 전달 테이블에 추가됩니다. 그러면 프레임이 모든 브리지 포트로 플러딩됩니다. VxLAN 인터페이스는 프레임을 원격으로 터널링하지만반품자신에게 보내십시오. 프레임을 "수신"하면 브리지에 복사되고 브리지는 VxLAN 포트에 도착하는 해당 MAC 주소의 프레임을 확인하고 그에 따라 포트 전달 테이블을 업데이트하여 VxLAN 포트를 veth 인터페이스에 도달하는 방법으로 기록합니다. MAC 주소.

DHCP 응답이 도착하면 브리지는 이를 확인하고, veth 인터페이스의 MAC 주소를 확인하고, 포트 전달 테이블을 쿼리하고, VxLAN 포트에서 본 마지막 MAC를 확인한 다음 이를 VxLAN 포트로 보냅니다. 그것은 결코 veth 항구에 도달하지 않습니다.

나에게 있어 이 분기의 요점은 브리지의 에이징 시간을 0으로 설정하면 브리지가 침수되기 때문에 문제가 "해결"된다는 것입니다.모든배달모든포트. 아마도 추가 fdb 항목을 찾아야 할 것입니다.

관련 정보