무엇보다도 mediatomb.clients를 사용하는 서버가 있습니다.단순 서비스 검색 프로토콜(SSDP)을 사용하여 네트워크에서 서버를 찾습니다.
SSDP 검색 쿼리가 응답을 받지 못하는 것을 발견 M-SEARCH하고 결국 서버가 브리지 인터페이스를 사용하고 있다는 사실에 대한 문제를 추적했습니다.멀티캐스트 청취활성화됨(브리지에서 기본적으로 이 기능을 활성화하기 때문)
내 문제를 해결했습니다.
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
그러나 내 경우에는 이것이 작동하지만 그것이 무엇을하고 있는지, 내가 알지 못하는 의미가 있는지 이해하지 못합니다. 그러므로 질문은....
멀티캐스트 스누핑이란 무엇이며, SSDP가 중단되는 이유는 무엇이며, 필요한 이유와 브리지에서 기본적으로 활성화되는 이유는 무엇이며, 기본적으로 활성화되어 있고 합당한 이유가 있으므로 비활성화하면 어떤 문제가 발생할 수 있습니까?
답변1
멀티캐스트는 스위치 라우터에 큰 부하를 줄 수 있습니다(잠재적인 DoS 공격의 보안 측면은 말할 것도 없고). 스위치(또는 Linux 브리지)에서멀티캐스트 청취네트워크 계층 2.5에 위치하며 다음을 통해 부하를 줄이도록 설계되었습니다.
- 네트워크 트래픽 스누핑
- 각 스위치 포트가 구독하는 멀티캐스트 채널 식별
- 기타 멀티캐스트 트래픽 필터링
멀티캐스트 트래픽을 디버깅하려는 경우가 아닌 이상 이는 항상 바람직한 기능인 것 같습니다. 그렇다면 멀티캐스트 청취를 비활성화하려는 이유는 무엇입니까?
몇 년 전 두 개의 서로 다른 호스트에 있는 두 개의 VM과 함께 Corosync를 사용할 때 내가 겪었던 버그에 직면했기 때문입니다. 들어오는 모든 멀티캐스트 트래픽이 호스트에 의해 삭제되는 것처럼 보일 때까지 트래픽은 괜찮았습니다 iptable. 완전히 비어 있음). AFAIK, 이것은 3.x 커널의 버그였으며 당신처럼 멀티캐스트 청취를 비활성화해야 했습니다. 내 기억이 맞다면 나는 Debian(Wheezy 또는 Jessie)을 사용하고 있었지만 이것은Red Hat 버그 보고서내가 겪고 있는 문제를 정확하게 설명합니다.
이 버그 보고서에 설명된 대로 가능하면 다음을 수행하는 것이 가장 좋습니다.
echo 1 > /sys/devices/virtual/net/br0/bridge/multicast_querier
비교하다:
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping