Почему мой Linux разместил бы многоадресную передачу получения остановки suddently? Все другие зарубки на частной сети получают

find инструмент является обычным для использования.

find . -name "*.html" \( -exec grep -q bluecar {} \; -o -exec rm {} \; \)

или

find . -name "*.html" ! -exec grep -q bluecar {} \; -exec rm {} \;

Но попробуйте его на копии сначала...

5
07.07.2012, 06:03
1 ответ

Я не знаю ни о какой политике истечения для состава группы IGMP в стеке Linux. Это может произойти, но я сомневаюсь относительно этого, так как существует по крайней мере два пути к ядру, которое будет сказано (одно явное, другое неявное), когда членство IGMP программы должно быть отброшено.

Поэтому я думаю, что у Вас есть ошибка в программном обеспечении, прислушивающемся к многоадресным пакетам. (Хотите назвать его?) Программа, получающая многоадресную передачу, так или иначе или отбросила свое собственное членство или забыла добавлять свое членство на запуске. При перезапуске многоадресной программы слушателя, tcpdump должен видеть IGMPv2 +, группа добавляет, что запрос членства выходит на сети.

Вы никогда не могли замечать эту ошибку при тестировании на маленькой LAN, так как дешевые сетевые коммутаторы не понимают IGMP. Функцию называют отслеживанием IGMP, и это только найдено в переключателях примерно 5× стоимость, на порт, самых дешевых единиц, или больше. Переключатель без способности к отслеживанию IGMP — или один с выключенной функцией — превращает многоадресную передачу в широковещательную передачу, таким образом, группа IGMP - добавляет, что сообщения не необходимы.

Вашему поставщику услуг хостинга, по-видимому, включили IGMP, шпионящий на их сетевой фабрике, начиная с многоадресных сообщений, остановленных, войдя после того, как состав группы IGMP ушел на сетевом стеке обеспокоенной машины.

Может также случиться так, что опции отслеживания IGMP поставщика услуг хостинга неправильно конфигурируются в переключателях, таким образом, они отбрасывают состав группы, но это не объясняет netstat -g результат.

3
27.01.2020, 20:41
  • 1
    Вы корректны относительно netstat-g. Мы используем hazelcast для этого. Я просто понял, что узлы без hazelcast, которые не должны даже слушать те многоадресные сообщения, согласно tcpdump все еще получают его - даже когда не часть группы - который прекрасен. Но это не объясняет, почему один узел, кажется, не получает их правильно. –  Tom G4 07.07.2012, 18:38
  • 2
    Продолжающийся прием mcast пакетов означает одну из двух вещей: 1. Вы однажды выполнили hazelcast на том узле, переключатель видел, что группа IGMP присоединилась, не видел отбрасывание группы и также - все еще отправляет пакеты... некоторые переключатели имеют "быстрый отпуск" функция для фиксации этого, но это может вызвать больше проблем, чем это решает; или 2. поставщик услуг хостинга не включил отслеживание IGMP, в этом случае у Вас есть некоторая проблема с самим узлом. Попробуйте тест tcpdump, искание группы IGMP добавляет запрос. –  Warren Young 07.07.2012, 18:48

Теги

Похожие вопросы