3gvanek

Вообще имхо лучше пользовать relay на l3, а на доступе только подсовывать option 82.

В чистокровном китайце S2300 V100R005C01SPC100 глюков не нашел, использовал option 82, dhcp snooping, arp inspection, loop detect, mvr, acl. На самом популярном в СНГ DES-3200 1.21.B006 тоже самое, только горят )) Вы о каком китае говорите? DCN? Zyxel? Edge-Core? Таки да - эти говно. S23 V1R5 да, уже более-менее ничего софт, но как Вы думаете, V1R6 просто так, для прикола сделали? V1R2 был вообще глюк на глюке, также и с edge-core, первые версии ПО висли через 5 минут после включения от любых management операций. Все софт правят, не только huawei, но проблема в том, что баги всё равно вылезают и без сервисного контракта можно остаться с проблемами один на один. У huawei есть преимущество - хороший БП, не виснут, когда проседает питание. Но факт остается - некоторые дешевые китайские свичи выполняют свои функции на ура уже СЕЙЧАС. А насчет софта я логику вообще понять не могу! Циска штампует IOS как горячие пирожки. И что же, циска - говно? IOS XE до сих пор глючный а ASR1k покупают аж бегом.

В чистокровном китайце S2300 V100R005C01SPC100 глюков не нашел, использовал option 82, dhcp snooping, arp inspection, loop detect, mvr, acl. На самом популярном в СНГ DES-3200 1.21.B006 тоже самое, только горят )) Вы о каком китае говорите? DCN? Zyxel? Edge-Core? Таки да - эти говно.

Я в конфиге не вижу ни 28 порта, ни вланов. Subnet 10.0.0.0/24 нужен для старта dhcpd и приема discover и request от релай агентов из этой же подсети. И если в ней менеджмент свичей, то идея выдавать туда адреса не очень удачная. Набросайте схему. Что куда включено и в какой влан.

Ничего не будет работать. Я так понимаю что на сервере 10.0.0.1 ? Нужно делать просто subnet 10.0.0.0 netmask 255.255.255.0 {} и не описывать ничего внутри.

Linksys SPS224, Huawei S2300, D-Link DES-3200 А вот на Zyxel лучше не смотреть и вообще не думать о нем ))

а вот это вопрос на самом деле, особенно если использовать пакетирование: То есть самый прямой выход - это фильтрация на каждом абонентском порту каждого SPTS потока IPTV, ну при 100 (допустим) каналах и 20 (допустим) портах - по крайней мере 2000! фильтров! Где тот коммутатор? Ну ладно, можно пакеты MPTS рассылать - по количеству пакетов, допустим... А как тогда быть с пропускной способностью? ведь подписавшись на одну группу абонент отхавает весь поток в 30 (опять допустим) каналов на 100 мегабит... Где то абонентское устройство? В общем, мне кажется что условный доступ только на CAS может быть реализован, на фильтрах - только если отрубать абоненту мультикаст полностью (то есть, без пакетирования), или на коммутаторах с ценой больше цены CAS. Или у кого-то есть решения работающие и я просто чего-то недопонимаю? О чем Вы? С какого перепугу абонент, подписавшись на одну группу отхватывает 30 ?? Фильтрами разрешаются join'ы на проплаченные группы, остальные join'ы режутся. Вот и весь условный доступ. P.S. Еще 5 раз перечитал Ваш пост - мозги расплавились )) MPTS каждому абоненту в ethernet сетях по мультикасту - это ересь ))

Дешево и сердито - костыль к билингу, скрипты для фильтрации igmp на абонентских портах. Дорого и правильно - купить нормальную Middleware с CAS, хомячки смотрят тв на stb или софтовым клиентом, умеющим этот самый CAS.

Ага, а смотреть отдельные куски конфига, например disp conf bgp - это тоже никому не надо? Вланы там добавляются аналогично циске.

Стоит за ним денек поработать и мнение очень сильно поменяется. Алу с длинками там рядом не стояли. Чего только один disp this стоит!

Нужен патч для вебморды - http://depositfiles.com/ru/files/b41lc401n

Ну, если Вы говорите, что получаете мультикаст от другого провайдера, то очевидно что у вас разные AS. То, что нет BGP - как раз и плохо. Дело в том, что идеологически гораздо правильней использовать Inter-domain multicast routing в случае обмена мультикастом между разными автономными системами. Этим собственно и являются msdp+mbgp как протоколы обнаружения источников мультикаста и маршрутизации в довесок к pim-sm. Хотя бы потому что такую схему легче дебажить и обслуживать. Вот представьте, что вы сейчас получили 100 ТВ-каналов от провайдера, написали статику на сорсы мультикаста и все вроде хорошо работает. Потом хитрые продажники решили этот мультикаст продавать разным домосетям в вашем городе. Вы с ними точно так же пиритесь, pim-sm, статика через вас до сорсов. А потом провайдер меняет адреса сорсов, или еще лучше - часть каналов берет где то еще, тоже с помощью pim. И что, всем заново статику переписывать? Зачем она нужна, если mbgp все роуты сам сложит в rpf таблицу? Зачем забивать основную таблицу маршрутизации или vrf'ы статикой на серые сети сорсов, если, например, эта серая адресация пересекается с вашей или ваших пиров? Тема маршрутизации мультика очень жаже обширная, поэтому вот вам в качестве примера http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094821.shtml По ключевым словам из этого гайда найдете много полезного на том же cisco.com

Городить один pim домен между разными as не очень кошерно. Попробуйте нагнуть провайдера мультика настроить msdp+mbgp. Сразу отпдут все проблемы с маршрутами до сорсов. RP и BSR лучше указывать кандидатами. Если не хочется прозрачно гнать мультик через цепочку каталистов со снупингом, можно настроть анонсы RP с первого каталиста. А на конце уже pim passive в сторону хомячков.

50. 625$ Так не бывает (с) к/ф "Джентльмены удачи".Шо это за прекрасная страна Эльдорадо, в которой 50 домов без нормального интернета и сотка стоит 20т.р.???? Украиной называется, а магистрал небось ett.

mls qos ! class-map match-any iptv match access-group 110 ! ! policy-map iptv_pol class iptv set dscp af41 ! access-list 110 permit udp any 234.1.1.0 0.0.0.255 range 1234 1234 и на портах, в которые приходит мультикаст - service-policy input iptv_pol Дальше на всех l2 свичах настраивайте dscp и будет вам счастье. P.S. никогда не гоняйте мультикаст в gvrp вланах.