OpenStack: обмен vms многоадресной передачей на eth1 перестал работать, когда каждый переносит тайм-аут IGMP

У меня есть два идентичных испытанных VMs, настроенные с dhcp для eth1. Я установил mgen и настроил mgen сценарии, чтобы иметь два обменных 1 многоадресное сообщение в секунду в течение 360 секунд. Один VM прекращает получать пакеты после 260 секунд (Тайм-аут IGMP Snooping Group). Второй VM продолжает получать сообщения в течение всего периода.

Я испытываю ту же проблему, если я использую идентичный CentOS 6.5 VMs.

Почему каждый работает? Почему делает другой тайм-аут и никогда не восстанавливаются?

Установка;

  • С помощью панели инструментов Гаваны я создал сеть с 10.16.1/24 подсетью, отключенным шлюзом, включил dhcp с диапазоном 10.16.1.100,10.16.1.120.

  • Запущенный 2 испытанных экземпляра, каждый с двумя NICS; eth0 для моего регулярного открытого интерфейса и eth1 для 10.16.1/24 подсети.

  • Вошедший каждый VM и созданный eth1.cfg, настроенный для dhcp

    auto eth1 iface eth1 inet dhcp

  • ifup eth1 на каждом vm

  • склонный - получают установку mgen на каждом vm

  • настройте один VM с этим mgen сценарием

    0.0 JOIN 224.225.1.104 INTERFACE eth1 0.0 LISTEN UDP 5104 10.0 ON 1 UDP SRC 5002 DST 224.225.1.103/5103 PERIODIC [1 512] 370.0 LEAVE 224.225.1.104 370.0 OFF 1

  • Настройте другой VM с дополнительным сценарием

    0.0 JOIN 224.225.1.103 INTERFACE eth1 0.0 LISTEN UDP 5103 10.0 ON 1 UDP SRC 5002 DST 224.225.1.104/5104 PERIODIC [1 512] 370.0 LEAVE 224.225.1.103 350.0 OFF 1

  • маршрут набора на каждом VM

    ip route add 224.225.1/24 dev eth1

  • запустите скрипт на каждом VM одновременно

    mgen input mcast.mgn

Как mgen выполнения это распечатывает сообщения, полученные от другого VM. Одна VM добирается до 260 секунд и прекращает получать;

18:50:35.414601 RECV proto>UDP flow 1 seq 251 src 10.16.1.103/5002 dst 224.225.1.103/5103 sent 18:50:35.304360 size 512 
18:52:04.672731 OFF flow 1 srcPort 5002 dst 224.225.1.104/5104

Другой завершается как ожидалось;

18:52:04.563455 RECV proto UDP flow 1 seq 341 src 10.16.1.104/5002 dst 224.225.1.104/5104 sent 18:52:04.672341 size 512 
18:52:05.305505 OFF flow 1 srcPort 5002 dst 224.225.1.103/5103

Что дает?

ОБНОВЛЕНИЕ

Используя wireshark на успешном VM показывает следующий трафик IGMP.

wireshark capture on successful VM

Обратите внимание, что успешная VM использует IGMPv2, в то время как провальный использует IGMPv3. Я не понимаю это, поскольку VMs создаются тождественно - то же базовое изображение - те же команды конфигурации - и т.д.

Кроме того, выполненные wireshark получают от сбоя VM. Интересно, это не получает ни одного из пакетов IGMPv2. Это, вероятно, объясняет, почему это никогда не отвечает на Запрос членства.

Согласно этому сообщению, IGMPv3 должен быть назад совместим с v2. Однако я действительно использовал эту информацию, чтобы вынудить сбой VM также использовать IGMPv2 и выполнил другое получение wireshark. Результат состоял в том, что сбой VM все еще не получает Запрос членства IGMP.

1
задан 23 May 2017 в 05:39

2 ответа

Потребность добавить брандмауэр управляет для разрешения IGMP в VM.

В Доступе Гаваны/Горизонта & безопасность, правила значения по умолчанию редактирования и добавляют новое правило;

  • Правило: Другое Направление Протокола
  • : Вход
  • Протокол IP: 2
  • Удаленный: CIDR
  • CIDR: 0.0.0.0/0
0
ответ дан 6 October 2019 в 18:55

Могла бы быть copy+paste ошибка, но у Вас может быть ошибка в маршруте, добавляет оператор, который Вы отправили. Маршрут для всего многоадресного диапазона: 224.0.0.0/4

оператор маршрута, который Вы отправили, может работать также, но первый октет Вашего оператора является неправильным (Вы имеете 225 вместо 224).

0
ответ дан 6 October 2019 в 18:55

Другие вопросы по тегам:

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