Да должен получать, но тут нужно проверить есть ли эта группа на вышестоящем коммутаторе в момент наличия проблемы.

Похоже, что зависимость есть.
Как быть?

_________________
D-Link Switches: Tips & Tricks

Попробуйте уменьшать Robustness в сторону умолчального значения до получения приемлемого результата.

Как раз для того чтобы получить приемлимый результат я его и выкрутил.
Если его уменьшить, то при быстрых переключениях каналов возможны рассыпания картинки у абонентов в соседних портах.
Если увеличить, то такой проблемы нет, но иногда появляется та, что описана в этой теме: клиент отписался, трафика в порт нет, а группа на порту висит.

_________________
D-Link Switches: Tips & Tricks

Воспроизвел ситуацию очень просто:

Ввел эти команды на том, что было под рукой (3028G) сразу после того, как STB отправил мембершип репорт.
Через 125 секунд (кстати, как переопределить это время?) коммутатор перестал отправлять поток в порт - на STB черный экран, трафика нет (проверил tcpdump'ом), а коммутатор рисует:

Через две минуты (не секунды!) запись пропала. Проверил несколько раз.

_________________
D-Link Switches: Tips & Tricks

На стенде я проверил и опять такой проблемы не вижу. Проверьте, чем у Вас отличаются следующие настройки на Querier и вышестоящих коммутаторах относительно тестируемого от стандартных:

Получается записи, которые коммутатор выводит для абонентских портов по команде show igmp_snooping host определяются трафиком с аплинка?
Объясните, пожалуйста, смысл этих записей, о чем они свидетельствуют?

_________________
D-Link Switches: Tips & Tricks

Вы не совсем поняли. Речь идет именно о наличии этой же группы на вышестоящих коммутаторах в момент, когда на коммутаторе группа есть, но трафик клиенту не приходит.

Везде по цепочке группа есть. Проверил еще раз:
1. Трафик пропадает через 125 секунд, либо через интервал host_timeout, если он меньше, чем 125 секунд.
2. Хост исчезает из списка через интервал host_timeout.
3. Если выставить host_timeout в 125 секунд или меньше, то трафик и хост пропадают одновременно.

Не пойму откуда берется значение в 125 секунд. Оно равно значению по умолчанию параметра query_interval, но это не то.

p.s. Membership report в тестах заблокирован.

_________________
D-Link Switches: Tips & Tricks

Вы на прошивке из подписи проверяете или на последней имеющейся на данный момент: 1.81.B006?

Модель указывал выше, прошивка из подписи 3028G(2.80-B08).

_________________
D-Link Switches: Tips & Tricks

На 3200, видимо, так:
Host_TTL = Query_Interval*Robustness_Value+Max_Response_Time
Т.е. по умолчанию =125*2+10=260

На 3028 так, как описал выше. И откуда берется значение в 125 секунд непонятно.

_________________
D-Link Switches: Tips & Tricks

Как я уже говорил, трафик должен пропасть, а группа еще может висеть, если мультикаст на аплинк не приходит, а ответы на Query со стороны клиента Вы заблокировали.
Поэтому я и спрашиваю, приходит ли вообще мультикаст на коммутатор через указанные 125 секунд? Если не приходит, то нужно на вышестоящем коммутаторе проверять, есть ли там запись в таблице IGMP Snooping и так далее по цепочке, чтобы определить, где эта рассинхронизация произошла.

Т.е. если в другом порту клиент будет смотреть этот же канал, то мультикаст на аплинк будет приходить и хост для, клиента, которому я заблокировал ответы, будет удален из списка сразу по истечении 125 секунд?

_________________
D-Link Switches: Tips & Tricks

Запись будет удалена по истечении счетчика, изменений тут не будет. Я говорю о том, что если запись есть, но трафика нет, значит его нет и на аплинке и значит один из вышестоящих коммутаторов не знает о том, что внизу еще нужен указанный канал. То есть где-то выше по цепочке запись об этом канале в этот момент отсутствует.