Всем привет!
Обнаружил странную особенность в работе IGMP Proxy режима на аппаратном фаерволе DFL-210. Прошивка свежая (2.26.00).

На стороне WAN-порта у меня находятся мультикастовые источники и IGMP Querier. На стороне LAN-порта находятся клиенты которым необходимо получать запрошенные ими мультикастовые потоки. Настраиваю DFL-210 для работы в режиме IGMP Proxy. Получается забавная штука - DFL шлет IGMP general query на оба своих порта (LAN и WAN)! То, что он шлет общий запрос на LAN-порт - это понятно и я с этим согласен. Но зачем его слать на WAN порт, где есть свой IGMP Querier?!
Заканчивается все довольно весело - свич, подключенный к WAN-порту, увидев IGMP general query сразу коммутирует на меня все мультикастовые потоки, которые на нем есть и я получаю флуд на WAN-интерфейсе этого фаервола.

В тестовых целях упростил задачу до минимума (без фильтраций, защиты и прочего) - результат тот же. В общих словах, тестовую конфигурацию создаю так:
1) создаю IGMP Rule для обработки IGMP Reports (client->server) с такими параметрами:
Type: Report (client->server)
Action: Proxy
Relay Interface: wan
Source Interface: lan
Source Network: lannet
Destination Interface: core
Multicast Source: all-nets
Multicast Group: m_group

2) создаю IGMP Rule для обработки IGMP Querys (server->client) с такими параметрами:
Type: Query (server->client)
Action: Proxy
Relay Interface: lan
Source Interface: wan
Source Network: all-nets
Destination Interface: core
Multicast Source: all-nets
Multicast Group: m_group

В качестве m_group у меня 224.0.0.0/4.


Кто-нибудь может прокомментировать данную ситуацию? И как ее исправить?

а если попробовать режим snoop ?

_________________
если человек - идиот, то это надолго

Спасибо за совет, но режим Snoop не подходит по своей идеологии....
В режиме Snoop IGMP-репорты от клиентов со стороны LAN-порта проходят в сеть на стороне WAN с неизменным "обратным IP адресом". А мне нужно, что-бы они были от имени DFL-210. А NATировать эти пакеты не возможно т.к. они идут из core.

У кого-нибудь есть еще идеи? Или это действительно БАГ?

- а если действовать по мануалу и конкретно прописать Multicast Source, Multicast Group ?
- мультикастовые источники и IGMP Querier находятся в одной подсети с ван-портом ?

_________________
если человек - идиот, то это надолго

Мультикастовые источники находятся в другой подсети и на WAN-порт фаервола попадают через роутер. Но это значения не имеет, т.к. о самих мультикастовых потоках речь не идет. Проблема с IGMP.

IGMP Querier находится в той же подсети, что и WAN-порт фаервола.

Прописывание конкретных значений Multicast Source и Multicast Group ни к чему хорошему не приводит. Изменение значения Multicast Source не на что не влияет, а изменение Multicast Group в некоторых случаях даже ухудшает ситуацию. Под ухудшением ситуации я подразумеваю следующее:
- Если в качестве Multicast Group указать весь диапазон 224.0.0.0/4, то на ситуацию можно влиять параметром IGMP Startup Query Count. Если установить его значение равным 1, то фаервол отправит на WAN-порт только оди IGMP general query. Свич, подключенный к WAN-порту, увидев этот запрос сразу скоммутирует на меня все мультикастовые потоки, которые на нем есть, но по истечению таймаута, установленного в этом свиче, флуд затихнет и можно будет спокойно работать до следующего перезапуска фаервола. Причем, значение параметра IGMP Startup Query Count не однозначно указывает сколько раз фаервол будет отправлять IGMP general query с WAN-порта при своем запуске. Например, если это значение равно 2 (по умолчанию), то фаервол отправляет 3 запроса. А если оно равно 1, то 1 запрос. К сожалению, значение IGMP Startup Query Count нельзя установить равным 0, чтобы вообще отключить отправку общих запросов с WAN-порта.
- Если в качестве Multicast Group указать урезанный диапазон (например - 224.0.42.0/24), то ситуацию нельза исправить даже параметром IGMP Startup Query Count - фаервол постоянно и с определенным интервалом шлет IGMP general query со своего WAN-потра.

Вот так! Есть у кого-нибудь еще идеи?

попробуйте удалить query-правило

_________________
если человек - идиот, то это надолго

Удалил Query-правило. Таким образом проблема с флудом изчезла, но появилась другая. Мультикастовые потоки прерываются. Причин этому как минимум две:
1) Я не рулю настройками IGMP Querier. Им ведает другой человек и в любой момент он может менять IGMP Query Interval, IGMP Query Response Interval и т.д. Соответственно, если IGMP Query Interval на IGMP Querier будет намного меньше, чем на DFL-210, то поток будет постоянно прерываться.
2) Если кто-то из клиентов на сивче со стороны WAN-порта покинет какую-то мультикастовую группу, то IGMP Querier вправе сделать запрос в эту группу, что-бы узнать - есть ли в этой группе еще слушатели и если их нет, то вещание потока будет прервано. Т.к. DFL-210 не обработает этот запрос, то и ответа на него не будет. Соответственно, вещание потока будет прервано.

Изъяснился криво, но надеюсь, что понятно.

Таким образом, удаление Query-правила не является правильным решением.

Есть у кого еще идеи?

попробуйте в "Source Network: all-nets" указать адрес "IGMP Querier"

_________________
если человек - идиот, то это надолго

Указал для Query-правила в "Source Network" вместо "all-nets" адрес "IGMP Querier".
Все-равно флудит....

У кого еще какие идеи?

возможно разрешить клиентам обмениваться с "IGMP Querier" напрямую, минуя посредничество длинка ?

_________________
если человек - идиот, то это надолго

Совсем минуя фаервол (т.е. мимо самой железки DFL-210) - нельзя.

а через дфл с помощью allow-правил можно ?

_________________
если человек - идиот, то это надолго

Ну, "политических" запретов на такой способ пока не наблюдаю (возможно потом появятся).
А вообще, я так уже пробовал - не получается прокинуть IGMP-пакеты с WAN на LAN и в обратную сторону. Делал по аналогии с тем, как пробрасываются мультикастовые UDP пакеты с WAN на LAN при работе с IPTV. Например, для проброса IGMP-репортов с LAN на WAN делал так:
1) Создаю IP-правило с такими параметрами:
Action: Multiplex SAT
Service: igmp
Schedule: (None)
Source Interface: lan
Source Network: lannet
Destination Interface: core
Destination Network: m_group
Multiplex Rule Interface: wan
Multiplex Rule IP Address: (None)

2) Создаю IP-правило с такими параметрами:
Action: Allow
Service: igmp
Schedule: (None)
Source Interface: lan
Source Network: lannet
Destination Interface: core
Destination Network: m_group

В качестве m_group у меня 224.0.0.0/4.

В итоге - не работает. На LAN-порт IGMP-репорты валятся, а с WAN они не выходят.
Если для обоих приведенных выше правил включить логирование, то видно, что отрабатывает только Allow-правило, а Multiplex SAT не отрабатывает. В результате, пакеты попадают в core и все - дальше никуда.

Может я не правильно делаю?

- неправильно
- удалите все igmp-правила, Multiplex SAT правила и т.д.
- уберите крыжик "IGMP before rules"
- уберите крыжик "Auto Add Multicast Core Route:"
- добавьте правило :
Action: Allow
Service: igmp
Schedule: (None)
Source Interface: any
Source Network: all_nets
Destination Interface: any
Destination Network: all_nets

_________________
если человек - идиот, то это надолго

Прошу прощения за долгое отсутствие.
Проблема по прежнему не решена!



Я попробовал сделать так, как вы предложили, но тоже ничего не получилось. Дело в том, что в этом д-линке прописан DEFAULT GW и поэтому все IGMP-пакеты, пришедшие с любого интерфейса, отправляются согласно этому маршруту на WAN-порт. Поэтому, когда со стороны WAN-порта от IGMP Querier приходят запросы, д-линк отправляет их по дефолтному маршруту обратно через WAN-порт.

Да и вообще, в этом DFL предусмотрена функция IGMP Proxy. Нужно использовать ее, а не искать обходные пути!

Получается, что это действительно глюк и функция IGMP Proxy работает не корректно?