Jump to content
Калькуляторы

DES XXXX igmp_snooping querier Сыпятся каналы при подключении интернета

Тестируем связку des-3200-26 (querier) <-> des-1228me (доступ) для IPTV+интернет. Мультикаст ходит, интернет тоже. Единственная проблема - как только подключаем к querier uplink от интернета картинка у абонента начинает сыпаться. Как только интернет от querier отключаем - картинка вновь становиться идеальной. Грешили сначала на левый мультикаст который идет по интернету в uplink querier (ибо весь мультикаст от абонов уже запретили). И фильтровали его и вообще мультикаст на этом порту запрещали. Все равно - как подключаем NAT (интернет) в querier картинка начинает сыпаться. Не понимаем из за чего это может происходить. Вот наши конфиги:

 

P.S. Да и еще пытались настроить Querier на другом свиче (думали дело в свиче) - не помогло.

 

des3200-26 (querier)

#25 порт - тегированный мультикаст

#26 порт - нетегированный интернет

config vlan default delete 1-26 advertisement disable

config vlan default add forbidden 1-26

 

create vlan iptv tag 1399

config vlan iptv add tagged 1-25

 

create vlan internet tag 1398

#25 порт идет на middleware в теге 1398 и на сервер вещания в 1399

config vlan internet add tagged 1-25

#26 порт к нему мы подключаем NAT (интернет)

config vlan internet add untagged 26

 

config ipif System dhcp

config ipif System vlan internet state enable

 

enable igmp_snooping

config igmp_snooping all state enable

config igmp_snooping querier all state enable

 

save

reboot

 

des1228 доступ

config vlan default delete 1-28 advertisement disable

config vlan default add forbidden 1-28

 

create vlan internet tag 1398

config vlan internet add untagged 1-24

config vlan internet add tagged 25-28

 

config ipif System dhcp

config ipif System vlan internet state enable

 

enable igmp_snooping

enable igmp_snooping multicast_vlan

create igmp_snooping multicast_vlan iptv 1399

config igmp_snooping multicast_vlan iptv state enable

config igmp_snooping multicast_vlan iptv add member_port 1-24

config igmp_snooping multicast_vlan iptv add source_port 25-28

config igmp_snooping multicast_vlan_group iptv add 239.195.0.0-239.195.5.255

config igmp_snooping vlan_name iptv fast_leave enable

config multicast port_filtering_mode all filter_unregistered_groups

Edited by el_misho

Share this post


Link to post
Share on other sites

Загрзука порта вместе с "интернетом" какая?

Какая аппаратная ревизия?

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

http://forum.nag.ru/forum/index.php?showtopic=60171&view=findpost&p=537805

Share this post


Link to post
Share on other sites

OoS не нужен.

3200-26 квариер не очень.

 

У нас квариевом в одном из районов выступает циска узловая, в другом случае длинк на L2 аггрегации.

Проблем нет.

Share this post


Link to post
Share on other sites

Насколько я понимаю, кверир просто шлёт запросы по таймеру чтобы узнать есть в группах ещё подписчики или нет. Если нет то снупинг выключает группу на порт без подписчиков.

Тут как бы без разницы кто шлёт, хоть адсл модем дохлый, главное чтобы слал вовремя правильно сформированные пакеты и чтобы они долетали до всех.

Share this post


Link to post
Share on other sites

Ivan_83, вот с таким вот мнением вы и забили на мультикаст в пользу юникаста. (я про дохлый адсл модем :) )

 

а если подходить к вопросу ответственно, то квериером действительно не стоит делать обычный коммутатор уровня доступа

 

сам с этим столкнулся, делал квериером 3028 который стоит в ядре сети и к которому были непосредственно подключены стримеры

 

картинка переодически останавливалась

 

Сейчас квериером выступает один из DGS-3610 на котором настроен pim. Но также обратите внимание, что квериер должен быть только один!

У меня не один 3610, а мультикаст телевидение везде идет в одном влане. И только один 3610 выступает квериером.

 

Кстати у топикстартера проблема вообще-то в рассыпании мультикаста, это не причина квериера ведь.

 

тут кокразтаки дело в QOS

Edited by mcdemon

Share this post


Link to post
Share on other sites

А подскажите плизз какие QoS правила необходимы? Включал

 

config cpu_filter l3_control_pkt 1-24 dvmrp pim igmp_query ospf rip vrrp state enable

 

не помогло(

Share this post


Link to post
Share on other sites
Ivan_83, вот с таким вот мнением вы и забили на мультикаст в пользу юникаста. (я про дохлый адсл модем :) )

Причин тому было много и кверир не в их числе.

Ещё я столкнулся с тем, что некоторые коммутаторы, у которых включён кверир, если видят запросы члетсва в группах от других коммутаторов то свой кверир отключают/он у них довольствуется чужими запросами.

Share this post


Link to post
Share on other sites

Может все банальнее? Проверьте на всякий случай настройки Storm Control, отключите safeguard.

Share this post


Link to post
Share on other sites

Ещё я столкнулся с тем, что некоторые коммутаторы, у которых включён кверир, если видят запросы члетсва в группах от других коммутаторов то свой кверир отключают/он у них довольствуется чужими запросами.

В IGMPv2 изначально каждый интерфейс, смотрящий в свой сегмент - querior, но как только он получает query от устройства с адресом меньшим, чем у него самого, он должен стать non-querior, перестать слать query и игнорировать leave с нисходящих интерфейсов. Его задача просто анализировать report, чтобы вести базу групп, которую потом тот же pim может заслать на RP.

Share this post


Link to post
Share on other sites

Раз уж зашел разговор про квериер. Насколько я понимаю, квериер шлёт игмп квери с адресом назначения 224.0.0.1, который таким образом долетает до всех устройств в ЛАН, а они в свою очередь отправляют репорты, которые вышестоящие коммутаторы отправляют в порт заранее известного мультикаст-роутера (квериера), а тот в свою очередь начинает передавать мультикаст в сторону запрашивающих. Но откуда мультикаст берется на квериере? Почему он подписывается на все группы в LAN? Какой механизм для этого используется? Не нашел описания этого в rfc.

При такой схеме работы квериер необходимо распологать как можно ближе к источнику трафика. Но как быть когда источников несколько и они находятся на некотором расстоянии друг от друга и от квериера, но по прежнему в пределах одной LAN? PIM? Тогда опять же должна быть только одна RP, но на неё трафик от источника ведь не льётся постоянно, а источник лишь регистрируется на ней? Тогда роль квериера для своего LAN выполняет каждый отдельный роутер?

Share this post


Link to post
Share on other sites

При такой схеме работы квериер необходимо распологать как можно ближе к источнику трафика

обычно, igmp querier крутится там же где и происходит pim-маршрутизация.

Share this post


Link to post
Share on other sites

Раз уж зашел разговор про квериер. Насколько я понимаю, квериер шлёт игмп квери с адресом назначения 224.0.0.1, который таким образом долетает до всех устройств в ЛАН, а они в свою очередь отправляют репорты, которые вышестоящие коммутаторы отправляют в порт заранее известного мультикаст-роутера (квериера), а тот в свою очередь начинает передавать мультикаст в сторону запрашивающих. Но откуда мультикаст берется на квериере? Почему он подписывается на все группы в LAN? Какой механизм для этого используется? Не нашел описания этого в rfc.

При такой схеме работы квериер необходимо распологать как можно ближе к источнику трафика. Но как быть когда источников несколько и они находятся на некотором расстоянии друг от друга и от квериера, но по прежнему в пределах одной LAN? PIM? Тогда опять же должна быть только одна RP, но на неё трафик от источника ведь не льётся постоянно, а источник лишь регистрируется на ней? Тогда роль квериера для своего LAN выполняет каждый отдельный роутер?

Вы смешиваете понятия немного. IGMP нужен лишь для того, чтобы маршрутизатор знал, какие получатели (именно получатели) есть за его интерфейсами. Для этого среди L2-сегмента выбирается querior, который шлет general query (и group specific query для v2, 3) на интерфейс (querior выбирается по принципу наименьшего ip адреса). На основании report от устройств, желающих получать мультикаст конкретной группы, строится таблица групп igmp на устройстве. Report, кстати, шлется на адрес группы, которая содержится в теле report, чтобы другие участники группы не заваливали report'ами сеть, а не на адрес querior (он его и так получит).

Маршрутизатор не будет передавать мультикаст на основе report/query или любых других пакетов от igmp. Маршрутизация мультикаст трафика происходит за счет работы протоколов маршрутизации мультикаста, ваш капитан, наиболее часто - это PIM. PIM анализирует результат работы igmp, на основе которого ведет MRT - multicast route table (либо SPT, либо Shared Tree в зависимости от типа PIM).

Для источника вообще не обязательно знать про igmp, pim и прочие вещи, он не делает join, report, он тупо шлет мультикаст на порт с адресом группы, если интерфейс, на который прилетает мультикаст от источника, pim-enabled, то PIM регистрирует его как (S,G) источник на RP, если это sparse, или начинает им тупо флудить в сеть до prune, если это dense.

 

В топике вообще обсуждается snooping querior, это вообще отдельное понятие, в cisco, насколько я помню используется в тех vlan'ах, где нет вышестоящего pim+igmp querior.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this