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

cisco + dlink = приоритезация мультикаста?

Нужна помощь по приоритезаци мультикаста в локальной сети. Как ни бьюсь - не выходит каменный цветок ;/

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

 

Схемка: мультикаст от аплинка приходит на 7606 (RSP720-3CXL-GE) по pim-sm.

Далее раcходится по нескольким 3750G - они работают шлюзами в юзерской локалке. Тоже по pim-sm. Кстати, 7606 (rp) -> несколько 3750g связь по pim в одном vlan, имеет ли это значение, может быть лучше до каждой отдельный влан для pim тянуть?

 

Ну и дальше -- длинки, dgs-3627, dgs-3100, des-3526, des-3028, des-3200 etc, etc

 

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

Поприотезировал всё на длинках по длинковским факам, на цисках по цисковским -- не помогает. Думаю, возможно будет легче с MVR (ISM) вланом, но очень уж не хочется на него переходить.

Кто как у себя решает проблемы приоритезации мультикаста?

 

Share this post


Link to post
Share on other sites

на 76й вешаем in/out полиси на интерфейс мультикастового влана с set dscp cs (cs2, cs3 или cs4 - зависит только от вашей общей стратегии), на портах mls qos vlan-based, на 3750 на портах mls qos trust dscp, а дальше на длинках приоретизацию особо можно и не трогать.

это как один из работающих вариантов...

Share this post


Link to post
Share on other sites
на 76й вешаем in/out полиси на интерфейс мультикастового влана с set dscp cs (cs2, cs3 или cs4 - зависит только от вашей общей стратегии), на портах mls qos vlan-based, на 3750 на портах mls qos trust dscp, а дальше на длинках приоретизацию особо можно и не трогать.

это как один из работающих вариантов...

Это приоритезирует трафик от RP (76xx) до аггрегаторов (3750), а они в свою очередь смаршрутизируют его по pim-sm и отдадут вновь без приоритета, как лучше приоритезировать в этом случае исходящий igmp от 3750?

Edited by Wingman

Share this post


Link to post
Share on other sites

самый простой вариант - исключить l3 с 3750 для мультикаста. тобишь с 76й спустить мультикастовый влан и развести его по mvr/ism.

но для начала попробуйте trust dscp ;)

https://supportforums.cisco.com/thread/2008119

тут товарищ как раз с pim-sm на 3750, и ему trust dscp на всех нужных интерфейсах помог ;)

Share this post


Link to post
Share on other sites
самый простой вариант - исключить l3 с 3750 для мультикаста. тобишь с 76й спустить мультикастовый влан и развести его по mvr/ism.

но для начала попробуйте trust dscp ;)

https://supportforums.cisco.com/thread/2008119

тут товарищ как раз с pim-sm на 3750, и ему trust dscp на всех нужных интерфейсах помог ;)

Понял, сейчас буду пробовать =) Очень уж не хочется на ism/mvr переползать...

Share this post


Link to post
Share on other sites

darkagent, что-то не выходит каменный цветок. То что идет транзитом через 7600 коробку то и остается размеченным, а вот то что красим на 7600 то за пределы 7600 не выходит. А можете еще и про очереди и трешолды пояснить?

 

Share this post


Link to post
Share on other sites
darkagent, что-то не выходит каменный цветок. То что идет транзитом через 7600 коробку то и остается размеченным, а вот то что красим на 7600 то за пределы 7600 не выходит. А можете еще и про очереди и трешолды пояснить?
мы сейчас говорим про конкретный случай Wingman'a, или вы попутно хотите затесать свой уникальный случай? ;)

 

для 76х можно полистать одну интересную книженцию джозефа и чапмана - deploying qos for cisco ip and next generation networks.

можно даже не покупать, на гуглокнижках она есть.

вот кстати прям сразу нужная глава: http://books.google.ru/books?id=bMKFYMql8u...ast&f=false

на рутрекере кстати лежит..

Edited by darkagent

Share this post


Link to post
Share on other sites

darkagent, схема очень похожая.

Есть 7604 SUP720 в нее подключены несколько источников мультикаста, причем один источник подключен непосредственно в 7604, второй и третий источники через несколько транзитных портов. На самой 7604 подняты int Vlan и pim-dm, дальше на районы отдаю по pim-dm. Второй и третий потоки покрашены заранее и они проходят раскрашенными через 7604 свободно и дальше я вижу эту раскраску, а вот с тем что крашу непосредственно на 7604 есть проблемы, по счетчикам красится, но на районном коммутаторе я этой раскраски уже не вижу, так что ситуация очень похожа.

 

За книжку спасибо.

 

Share this post


Link to post
Share on other sites

Насколько я помню - все нормально красилось... Только был нюанс - красит только на выходе, на входе игнорирует... Но не ругается...

 

Вы случайно не на input`е красить пытаетесь? Попробуйте на output`e

 

 

Share this post


Link to post
Share on other sites
Tosha, да на inpute, спасибо попробую на outputе. А почему такой нюанс то?

Share this post


Link to post
Share on other sites

Tosha, да на inpute, спасибо попробую на outputе. А почему такой нюанс то?

output - это тот трафик, который вы отдаете. а на input - тот трафик, который вы получаете. очевидно ж.

Share this post


Link to post
Share on other sites

darkagent, не совсем очевидно. Потоки которые я принял ранее, я крашу непосредственно на тех портах в которые подключены источники и крашу именно путем применения service-policy input MCAST, дальше поток идет на 7604 покрашенным и проходит через порт на котором есть mls qos trust dscp, аналогично я попытался покрасить тот поток источник которого подключен в untrust порт самой 7604, причем на порту было service-policy input MCAST и по sh mls qos ip и sh policy-map int эта раскраска была видна. Так что этот нюанс какой то сильно специфический.

 

 

Share this post


Link to post
Share on other sites

ну смотри, у тебя есть какой то поток, предположим в определенном влане. ты его принимаешь на каком то порту 7604, не крашенным. и дальше, ты отдаешь передаешь этот поток куда-либо, обработанный или нет (l2/l3). навешивая service-policy input на интерфейс, ты определяешь правила покраски только для входящих очередей, таким образом ты указываешь железке что она должна этот поток правильно принять. никто не говорит что она будет отдавать его дальше крашенным, ты его покрасил только для внутреннего приема. и если тебе хочется этот поток отдать дальше - тебе надо указать правила покраски исходящей очереди для данного потока, поэтому тебе нужно определять правила для service-policy output. даже если это все в пределах одного vlan, и он проходит как l2. т.е.

в итоге у тебя должно получиться что то вроде:

policy-map tv

class class-default

set dscp cs4

!

 

int vlan 100

service-policy input tv

service-policy output tv

no shut

!

 

int g1/1

desc input

mls qos vlan-based

!

int g1/2

desc ouput

mls qos vlan-based

!

int g1/3

desc output2

mls qos vlan-based

!

 

 

Share this post


Link to post
Share on other sites

У меня вроде всё красится, подлагивания всё равно остались. Сегодня проведём эксперимент, воткнемся ноутом в единственный медный порт на 76, если будет лагать - останется пинать поставщика =)

Share this post


Link to post
Share on other sites

У меня вроде всё красится, подлагивания всё равно остались. Сегодня проведём эксперимент, воткнемся ноутом в единственный медный порт на 76, если будет лагать - останется пинать поставщика =)

Если уж собрались давать абонентам iptv, то разумно будет собрать стенд, который будет работать в равных с абонентами условиях, например поставить тв-приставку или ПК с vlc за пачкой коммутаторов.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

С этого и нужно было начинать. Мы тоже почти месяц биллись над похожей проблемой, думали у нас что-то где-то теряется, а нет, все оказалось куда проще с ГС шел гавносигнал.

Share this post


Link to post
Share on other sites

Забавно, у 3750 как раз наоборот, красятся пакеты только на входе, на выходе service-policy не умеет.

Ещё надо отключать mls qos rewrite dscp, иначе сбрасывает в ноль всё, даже при настроенном service-policy.

И наконец, в нашем IOS нет возможности переписать 802.1p priority, так что пришлось его назначать на длинке L2-уровня, что прокидывает vlan на циску, а на 3750 оставить раскрашивание DSCP.

 

Кстати, рекомендую почитать Cisco Catalyst 3750 QoS Configuration Examples

Edited by Dyr

Share this post


Link to post
Share on other sites

Доброе время суток!

Посоветуйте как настроить qos на всей ветки (источник---->0/12 cisco 3550 0/10 ----> dlink 3120-----> dlink3526-----> dlink3200--->получатель iptv),что бы при просмотре iptv не сыпались каналы.

 

конфигурация cisco:

mls qos

!

ip multicast-routing

ip igmp snooping vlan 111 mrouter interface Gi0/12

vtp domain tradc

vtp mode transparent

 

interface GigabitEthernet0/10

mls qos trust dscp

mls qos monitor dscp 8 32 34

 

interface GigabitEthernet0/12

mls qos trust dscp

mls qos monitor dscp 8 32 34

 

в длинках настроен только влан 111

Edited by user-201

Share this post


Link to post
Share on other sites

У меня тоже вопрос. LACP 3х1gb. Идет пиринг 2 гигабита и иптв 400 мбит. Может сыпать из-за LACP? С пирингами проблем нет никаких...

Share this post


Link to post
Share on other sites

У меня тоже вопрос. LACP 3х1gb. Идет пиринг 2 гигабита и иптв 400 мбит. Может сыпать из-за LACP? С пирингами проблем нет никаких...

 

LACP парная технология, поднимайте еще один линк.

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