Судя по вашим комментариям, проблема заключалась в том, что на одном из коммутаторов было включено отслеживание IGMP. Отключение отслеживания IGMP решило проблему, но это на самом деле не идеально. Это действительно сводится к тому, что у вас не было многоадресного запроса или mrouter, подключенного к коммутаторам.
Не существует ли програматического c способа сказать: "не sn oop или задержать этот пакет "?
Нет, это сетевая конфигурация, которая полностью зависит от моделей коммутаторов и их конфигурации.
Отключение отслеживания IGMP на коммутаторах фактически все хосты получают многоадресные рассылки, а это может быть нежелательно (вероятно, нежелательно). Протоколы многоадресной рассылки, в отличие от протоколов одноадресной рассылки, предназначены для предотвращения отправки многоадресной рассылки туда, где она не запрашивалась. Отслеживая IGMP, коммутатор увидит сообщения о присоединении от хоста и отправит многоадресные кадры для запрошенной группы на интерфейс коммутатора, к которому подключен этот хост, но не на все интерфейсы, где он не был запрошен. Это экономит потерянную пропускную способность на интерфейсах и каналах, где многоадресная рассылка не нужна.
У вас не возникнет проблемы, которую вы сделали, если бы на обоих коммутаторах было включено отслеживание IGMP и к вам был подключен многоадресный запрос или mrouter. Может быть возможно настроить один из ваших коммутаторов как многоадресный запрос для решения проблемы.
Это выдержка из ответа на Сетевая инженерия :
Объяснение Cisco проблемы:
Описание проблемы и ее решений
По умолчанию на коммутаторах Catalyst включено отслеживание IGMP , При отслеживании IGMP коммутатор отслеживает (или прослушивает) сообщения IGMP на всех портах. Коммутатор создает таблицу отслеживания IGMP, которая в основном отображает группу многоадресной рассылки на все запрашивающие ее порты коммутатора.
Предположим, что без какой-либо предварительной конфигурации Receiver 1 и Receiver 2 сообщили о своих намерениях получить многоадресную рассылку. поток для 239.239.239.239, который сопоставляется с многоадресным МА2-адресом L2 с адресом 01.00.5e.6f.ef.ef. И коммутатор 1, и коммутатор 2 создают записи в своих таблицах отслеживания для этих получателей в ответ на отчеты IGMP, которые генерируют получатели. Коммутатор 1 вводит порт Gigabit Ethernet 2/48 в свою таблицу, а Коммутатор 2 вводит порт Fast Ethe rnet 1/0/47 в свою таблицу.
Примечание: На этом этапе источник многоадресной рассылки не начал свой трафик c, и ни один из коммутаторов не знает о порте коммутатора коммутатора.
Когда источник на коммутаторе 1 начинает передавать многоадресный трафик c, коммутатор 1 "видел «Отчет IGMP от Получателя 1. В результате Коммутатор 1 доставляет многоадресный порт Gigabit Ethe rnet 2/48. Но, поскольку Коммутатор 2 «принял» отчет IGMP от Receiver 2 как часть процесса отслеживания IGMP, Коммутатор 1 не видит отчет IGMP (многоадресный запрос) на порте Gigabit Ethe rnet 2/46. В результате коммутатор 1 не отправляет трафик многоадресной рассылки c на коммутатор 2. Поэтому Receiver 2 никогда не получает трафик многоадресной рассылки c, даже если Receiver 2 находится в той же VLAN, но просто на другом коммутаторе, чем источник многоадресной рассылки.
Причиной этой проблемы является то, что отслеживание IGMP на самом деле не поддерживается ни на одной платформе Catalyst без mrouter. Механизм «ломается» при отсутствии порта для mrouter. Если вы хотите исправить это решение, коммутаторы должны как-то узнать или узнать порт mrouter. Раздел «Решения» этого документа объясняет процедуру. Но как присутствие порта коммутатора на коммутаторах исправляет ситуацию?
В основном, когда коммутаторы узнают или статически знают о порте коммутатора, происходят две критические вещи:
- Коммутатор «ретранслирует» отчеты IGMP от приемников на порт mrouter, что означает, что IGMP сообщает go в направлении многоадресного маршрутизатора. Коммутатор не передает все отчеты IGMP. Вместо этого коммутатор отправляет только несколько отчетов в mrouter. Для целей данного обсуждения количество отчетов не имеет значения. Маршрутизатору многоадресной рассылки нужно только знать, существует ли хотя бы один получатель, который все еще заинтересован в многоадресной рассылке. Чтобы сделать определение, многоадресный маршрутизатор получает отчеты IGMP periodi c в ответ на свои запросы IGMP.
- В сценарии многоадресной передачи только для источника, в котором еще не «подключены» приемники, коммутатор только отправляет многоадресный поток через свой порт mrouter.
Когда коммутаторы знают свой порт mrouter, коммутатор 2 передает отчет IGMP, который коммутатор получил от Receiver 2, на свой порт mrouter. Этот порт Fast Ethe rnet 1/0/33. Коммутатор 1 получает этот отчет IGMP о порте коммутатора Gigabit Ethe rnet 2/46. С точки зрения коммутатора 1, коммутатор получил просто еще один отчет IGMP. Коммутатор добавляет этот порт в свою таблицу отслеживания IGMP и начинает отправлять многоадресный трафик c также на этот порт. На этом этапе оба получателя получают запрошенный многоадресный трафик c, и приложение работает, как и ожидалось.
Но как коммутаторы идентифицируют свой порт mrouter, чтобы IGMP Snooping работал так, как ожидается, простая среда, как это? В разделе «Решения» приведены некоторые ответы.
Объяснение HP проблемы:
Когда коммутатор получает соединение IGMP, он принимает запрос хоста и начинает пересылку трафика IGMP c. Это означает, что порты, которые не присоединились к группе и не подключены к маршрутизаторам или IGMP Querier, не получат групповой трафик группы c.
Похоже, что вы можете настроить коммутаторы как IGMP Queriers:
Использование коммутатора в качестве Querier
Работа Querier
Функция IGMP Querier заключается в опросе других устройств с поддержкой IGMP в VLAN с поддержкой IGMP для получения информации о членстве в группе. Коммутатор выполняет эту функцию, если в VLAN нет другого устройства, такого как многоадресный маршрутизатор, для выполнения функции Querier. Хотя коммутатор автоматически прекращает работу Querier в VLAN с поддержкой IGMP, если он обнаруживает другой Querier в VLAN, вы также можете использовать командную строку для отключения возможности Querier для этой VLAN.
Примечание Для корректной работы IGMP требуется Querier. По этой причине, если вы отключите функцию Querier на коммутаторе, убедитесь, что в той же VLAN доступен IGMP Querier (и, предпочтительно, резервный Querier).
Если коммутатор становится Querier для После того, как определенная VLAN (например, DEFAULT_VLAN) затем обнаруживает запросы, переданные с другого устройства в той же VLAN, коммутатор перестает работать как Querier для этой VLAN. Если это происходит, в журнале событий коммутатора отображается пара сообщений, подобных этим:
I 01/15/01 09:01:13 igmp: DEFAULT_VLAN: Other Querier detected
I 01/15/01 09:01:13 igmp: DEFAULT_VLAN: This switch is no longer Querier
В приведенном выше сценарии, если другое устройство перестает работать как Querier в VLAN по умолчанию, коммутатор обнаруживает это изменение и может стать Querier, если он не заменен каким-либо другим IGMP Querier в VLAN. В этом случае журнал событий коммутатора перечисляет сообщения, подобные следующим, чтобы указать, что коммутатор стал Querier в VLAN:
I 01/15/01 09:21:55 igmp: DEFAULT_VLAN: Querier Election in process
I 01/15/01 09:22:00 igmp: DEFAULT_VLAN: This switch has been elected as Querier