dgs3627 прошивка r255b05.

В результате экспериментов выяснилось следующее:
1) если igmp_snooping выключен глобально, то limited_multicast_range фильтр не применяется.
2) если igmp_snooping включен глобально, то limited_multicast_range фильтр применяется к порту целиком (т.е. ко всем vlan'ам в этом порту, в том числе и к тем в которых igmp_snooping выключен).

А теперь вопрос - как сделать, чтобы igmp_snooping работал для vlan'а X, трафик в vlan'е X фильтровался бы limited_multicast_range фильтром, при этом, чтобы в vlan'е Y (из того же порта, что и vlan X) проходил весь мультикастный трафик?

Вообще-то Limited Multicast address ranges функция настраиваемая как раз на порту. А что мешает настроить её на доступе?

Клиенты бывают разные. Некоторым нужно странное.

Т.е. я правильно понял, что описанное поведение багом не является?
Просто подобное поведение не выглядит логичным.

Багом не является. А в чём нелогично поясните пожалуйста?

Нелогично то, что невозможно нормально фильтровать мультикаст при включенном igmp_snooping:

- если igmp_snooping выключен, мультикаст можно фильтровать обычными acl'ями на порту.
- стоит включить igmp_snooping глобально - обычные acl'и для мультикаста перестают работать.
- limited_multicast_range, который начинает работать при включенном igmp_snooping'е не позволяет фильтровать мультикаст в конкретном vlan'е - только на проту.

В результате получается: либо igmp_snooping, либо мультикастные фильтры.
Логично было бы если бы limited_multicast_range не применялся бы к vlan'ам, в которых igmp_snooping не включен. Или если бы мультикаст трафик из vlan'ов с отключенным igmp_snooping'ом автоматом не направлялся бы на CPU (т.е. можно было бы его фильтровать обычными acl'ями).

P.S. то, что мне было нужно - я сделал. Но данное решение "прямым" назвать сложно - ибо фильтровать мультикаст cpu acl'ями, на мой взгляд, не самое разумное решение.

К сожалению это аппаратное ограничение устройства. Рад что у Вас всё получилось!