el_misho Опубликовано 19 января, 2014 (изменено) · Жалоба Тестируем связку 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 Изменено 19 января, 2014 пользователем el_misho Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 19 января, 2014 · Жалоба Загрзука порта вместе с "интернетом" какая? Какая аппаратная ревизия? Возможно дело в маленьких буферах портов, как только начинается разноплановый трафик, некоторые нужные пакеты дропаются. http://forum.nag.ru/forum/index.php?showtopic=60171&view=findpost&p=537805 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 19 января, 2014 · Жалоба Надо QoSить. Да и то не факт, из свитча доступа квариер никакой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 19 января, 2014 · Жалоба OoS не нужен. 3200-26 квариер не очень. У нас квариевом в одном из районов выступает циска узловая, в другом случае длинк на L2 аггрегации. Проблем нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 19 января, 2014 · Жалоба OoS не нужен. Даром попробовать то можно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 января, 2014 · Жалоба Насколько я понимаю, кверир просто шлёт запросы по таймеру чтобы узнать есть в группах ещё подписчики или нет. Если нет то снупинг выключает группу на порт без подписчиков. Тут как бы без разницы кто шлёт, хоть адсл модем дохлый, главное чтобы слал вовремя правильно сформированные пакеты и чтобы они долетали до всех. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mcdemon Опубликовано 20 января, 2014 (изменено) · Жалоба Ivan_83, вот с таким вот мнением вы и забили на мультикаст в пользу юникаста. (я про дохлый адсл модем :) ) а если подходить к вопросу ответственно, то квериером действительно не стоит делать обычный коммутатор уровня доступа сам с этим столкнулся, делал квериером 3028 который стоит в ядре сети и к которому были непосредственно подключены стримеры картинка переодически останавливалась Сейчас квериером выступает один из DGS-3610 на котором настроен pim. Но также обратите внимание, что квериер должен быть только один! У меня не один 3610, а мультикаст телевидение везде идет в одном влане. И только один 3610 выступает квериером. Кстати у топикстартера проблема вообще-то в рассыпании мультикаста, это не причина квериера ведь. тут кокразтаки дело в QOS Изменено 20 января, 2014 пользователем mcdemon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
el_misho Опубликовано 20 января, 2014 · Жалоба А подскажите плизз какие QoS правила необходимы? Включал config cpu_filter l3_control_pkt 1-24 dvmrp pim igmp_query ospf rip vrrp state enable не помогло( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 января, 2014 · Жалоба Ivan_83, вот с таким вот мнением вы и забили на мультикаст в пользу юникаста. (я про дохлый адсл модем :) ) Причин тому было много и кверир не в их числе. Ещё я столкнулся с тем, что некоторые коммутаторы, у которых включён кверир, если видят запросы члетсва в группах от других коммутаторов то свой кверир отключают/он у них довольствуется чужими запросами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 20 января, 2014 · Жалоба Может все банальнее? Проверьте на всякий случай настройки Storm Control, отключите safeguard. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tehmeh Опубликовано 20 января, 2014 · Жалоба Ещё я столкнулся с тем, что некоторые коммутаторы, у которых включён кверир, если видят запросы члетсва в группах от других коммутаторов то свой кверир отключают/он у них довольствуется чужими запросами. В IGMPv2 изначально каждый интерфейс, смотрящий в свой сегмент - querior, но как только он получает query от устройства с адресом меньшим, чем у него самого, он должен стать non-querior, перестать слать query и игнорировать leave с нисходящих интерфейсов. Его задача просто анализировать report, чтобы вести базу групп, которую потом тот же pim может заслать на RP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minya Опубликовано 21 января, 2014 · Жалоба Раз уж зашел разговор про квериер. Насколько я понимаю, квериер шлёт игмп квери с адресом назначения 224.0.0.1, который таким образом долетает до всех устройств в ЛАН, а они в свою очередь отправляют репорты, которые вышестоящие коммутаторы отправляют в порт заранее известного мультикаст-роутера (квериера), а тот в свою очередь начинает передавать мультикаст в сторону запрашивающих. Но откуда мультикаст берется на квериере? Почему он подписывается на все группы в LAN? Какой механизм для этого используется? Не нашел описания этого в rfc. При такой схеме работы квериер необходимо распологать как можно ближе к источнику трафика. Но как быть когда источников несколько и они находятся на некотором расстоянии друг от друга и от квериера, но по прежнему в пределах одной LAN? PIM? Тогда опять же должна быть только одна RP, но на неё трафик от источника ведь не льётся постоянно, а источник лишь регистрируется на ней? Тогда роль квериера для своего LAN выполняет каждый отдельный роутер? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 21 января, 2014 · Жалоба При такой схеме работы квериер необходимо распологать как можно ближе к источнику трафика обычно, igmp querier крутится там же где и происходит pim-маршрутизация. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tehmeh Опубликовано 21 января, 2014 · Жалоба Раз уж зашел разговор про квериер. Насколько я понимаю, квериер шлёт игмп квери с адресом назначения 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...