Мультикаст и должен работать с этими правилами. Для мультикаста нужно фильтровать destination_ip, а не source_ip. Но если в этих правилах просто source поменять на destination, то IPTV работать перестанет... выше писали почему.

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

Мультикаст во многих системах используется и многим оборудованием - ненароком можно зафильтровать что-то нужное. В вашем случае может даже стандартной настройки и ограничения по группам хватит на этом свиче и фильтровать с помощью ACL ничего не придется.

В качестве временного решения (которое у многих останется постоянным) можно на DGS-1100-10/ME включить IGMP Querier в абонентском VLAN. IPTV работать будет.

Но отправку General Query на Uplink все же нужно как-то устранить. Egress фильтров на D-Link ведь нет, а вышестоящий свич может вообще не уметь фильтровать такие пакеты или, если там тоже D-Link, все CPU ACL на нем могут быть уже заняты другими правилами.

здравствуйте,

вопрос вендору.
можно ли донести программистам чтобы добавили команду просмотра связки IP-MAC binding для данного свича и для 1100-06/ME конкретно интересует любая из этих двух или что-то типа того
show address_binding dhcp_snoop binding_entry
show address_binding ip_mac all
а то свич сам по себе замечательный, всё работает, dhcp snooping всё нормально снупает, опцию 82 обрабатывает, пользователи адреса получают, но эксплуатировать очень неудобно, ибо проверить на свиче, что и кому выдалось и выдалось и выдалось ли вообще - невозможно, нужно только лезть в биллинг (((

это возможно и реально или "все в сад" (с)?

ps: про security ладно, не будем, дабы не наглеть уж совсем workaround есть - и то хорошо.

Ни на DGS-1100-10/ME, ни на DGS-1100-06/ME нет IMPB и не планируется. Соответственно, dhcp snooping тоже не будет.

что исправили/добавили в 44-ой?
после установки 43-ей несколько свичей повисло, примерно 4 из 60.Под повисло я имею ввиду не повисло в процессе обновления а после успешного рубута и какого-то время эксплуатации.Можно ли получить дебаг версию что бы поиочь Вам исправить этот глюк до конца?

На официальном сайт есть информация:



Что по-русски звучит как:
1. Исправлена настройка портов
2. Добавлена возможность настройки vlan группой

Описание на сайте исправлено, спасибо за замечание.

Артем, рассмотрели функционал этого свича касательно работы с мультикастом... там такая каша. Свичей этих много, время идет, а воз и ныне там. Одно починили - другое сломали. Может дадите контакты разработчиков, чтобы напрямую о недоработках им писать (там много), а не Вас здесь терзать?

Пишите сюда, напрямую мне, или моим коллегам, на почту.

Хорошо.

Тогда опять о IGMP General Query и IGMP Reports:

• 1. DGS-1100-10/ME отправляет его на Uplink, что может спровоцировать вышестоящий свич отправить ему весь имеющийся на нем мультикаст-трафик (или только все IGMP пакеты), который DGS-1100-10/ME не нужен. Это может привести к неприятным последствиям описанным далее в пункте 3.
• 2. DGS-1100-10/ME не пропускает через себя IGMP General Query на клиентские порты и от своего имени их не дублирует и на Uplink на них сам не отвечает (а тем временем, на вышестоящем свиче/роутере работает счетчик ждущий ответа на этот Query и по его истечению трансляция UDP вышестоящим свичем/роутером прекращается). Думал, что включение Querier на DGS-1100-10/ME поможет, но ошибался.
• 3. DGS-1100-10/ME пропускает IGMP Reports (V2 по крайней мере), приходящие ему на Uplink (возможно и с клиентских портов), на абонентские порты, хотя в RFC4541 section 2.1.1.1 прямо сказано: "A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached.". В некоторых случаях (при определенном сочетании оборудования, работающего по RFC или не по ним) это может спровоцировать обрывы в трансляции, RFC2236: "If the host receives another host's Report (version 1 or 2) while it has a timer running, it stops its timer for the specified group and does not send a Report, in order to suppress duplicate Reports.". Обрывы происходят примерно каждые 2 минуты (зависит от интервала отправки General Query роутером, рандомного счетчика у клиента и количества других клиентов подписанных на ту же группу).

Все это при настроенном ISM VLAN и включенном IGMP Snooping, естественно. Если что-то непонятно, то могу пояснить.

Разработчики уже в курсе. Работа по проблеме с ISM Vlan и IGMP Query уже ведется.

ну сам снупинг-то работает, хоть его и нет: пакет снупается, в него добавляется корректная опция82. всей-то радости сделать занесение пары ip-mac из пакета dhcpack в отдельную таблицу. даже в самом худом случае, если ограничиться одной записью на порт - это (4+6)*10=100 байт в оперативной памяти. лично я не вижу вообще никаких препятствий, кроме маркетинговых. других никаких требований нет, к безопасности подвязывать это не нужно.

Думаете маркетинга мало?

Применяем на DGS-1100-10/ME Build V1.01.B043 (аплинк 10 порт)
create cpu_access_profile ip source_ip_mask 240.0.0.0 profile_id 3
config cpu_access_profile profile_id 3 add access_id 1 ip source_ip 224.0.0.0 port 1-10 deny
и напрочь теряем управление
Поясните пожалуйста причину

_________________
ISP LuxLite

sansiam

Это не снупинг, это relay. Снупинг - это надстройка над IMPB, которого в этой модели нет, а значит и снупинга быть не может.