[undro]

Приветствую всяк сюда заглянувших.

 

Схема как то так: homeip -> магистрал -> SNR-S2970-12X -> X670V-48X -> ГСКТВ

 

Берем несколько HD каналов у homeip, поток 30-35M.

Магистрал на нашем стыке (магистрал -> SNR-S2970-12X) отдает vlan с этими каналами.

На SNR два портченела по 3х10G в lacp, к нам и к магистралу, трафика в пике 20G.

В ЧМН, на X670V имеем CC error в кол-ве ~500/час. Ошибок на физике нет. Каналы сыпят.

На SNR CC error по нулям.

Для теста выдернул один линк из портченела, пустил каналы по нему, CC error по нулям, картинка сыпать перестала.

Как связать этот феномен с портченелом, не пойму...

 

И да, балансинг на SNR - src/dst ip.

[mikezzzz]

а на оставшемся ПЧ ошибки прекратились когда линк выдергивали под IPtv?

дайте конфиги посмотреть :)

[Butch3r]

Да, не любит телек LACP. Тоже боролся, боролся и сделал отдельный линк...

Уменьшает проблему QOS, но полностью не решает.

[v_r]

Для теста выдернул один линк из портченела, пустил каналы по нему, CC error по нулям, картинка сыпать перестала.

 

По опыту настройки IPTV очень сильно помогает нормальный QoS на свитчах, точнее сказать без него вообще не обойтись если линк загружен больше чем на половину. Возможно у вас картинка перестала сыпать потому что трафик на отдельном линке был минимальный.

Ну и плюс я не уверен что каждая CC ошибка проявляется в виде рассыпания картинки. CC - continuity counter, ошибка может возникать как из-за перестановки пакетов на LACP (на некоторых свитчах такое бывает) так и при дропах трафика при нехватке буферов у свитча, посмотрите счетчики discards in/out на интерфейсах.

[Butch3r]

Для теста выдернул один линк из портченела, пустил каналы по нему, CC error по нулям, картинка сыпать перестала.

 

По опыту настройки IPTV очень сильно помогает нормальный QoS на свитчах, точнее сказать без него вообще не обойтись если линк загружен больше чем на половину. Возможно у вас картинка перестала сыпать потому что трафик на отдельном линке был минимальный.

Ну и плюс я не уверен что каждая CC ошибка проявляется в виде рассыпания картинки. CC - continuity counter, ошибка может возникать как из-за перестановки пакетов на LACP (на некоторых свитчах такое бывает) так и при дропах трафика при нехватке буферов у свитча, посмотрите счетчики discards in/out на интерфейсах.

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

[undro]

а на оставшемся ПЧ ошибки прекратились когда линк выдергивали под IPtv?

дайте конфиги посмотреть :)

На оставшемся бегал абонентский интернет, с ним проблем нет.

В конфигах ничего интересного, голый l2 с вланами и lacp.

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

Тоже этот вариант рассматривал. Не думал, что это может быть критично. Линки равноудаленные, в ЧМН загружены на 2/3, да и балансировщик диктует мультикасту ходить через один линк.

Решаем вопрос дополнительного стыка под это дело.

 

это зависит от степени сжатия картинки

По нашим наблюдениям, в dvb-c подсыпания становились заметными уже при рейте 50-100 ошибок в час.

[Butch3r]

тут зависит сколько ошибок идёт подряд. мультиплекс, который вещается в T2 - даже 1 СС видно на картинке. А вот с mpeg2 кодеров даже 10CC не всегда заметно

[v_r]

Тоже этот вариант рассматривал. Не думал, что это может быть критично. Линки равноудаленные, в ЧМН загружены на 2/3, да и балансировщик диктует мультикасту ходить через один линк.

Решаем вопрос дополнительного стыка под это дело.

 

Поле CC имеет значение от 0 до 15, насколько понимаю CC ошибка возникает если пакеты пришли не по порядку, такое может быть при дропе пакетов либо перестановке пакетов местами.

Дропы из-за нехватки буферов отображаются в статистике QoS и интерфейса если свитч их считает (считают почти все свитчи), с SNR-S2970 не сталкивался, не скажу.

Вы уверены что балансировщик работает верно и таки направляет мультикаст всегда в один порт? Может настройки вляют только на юникаст трафик?

 

У нас на dvb-c ошибки часто подсыпают:

Jan 26 14:15:52: ERROR: CC: PID:*=1 PID:*=1 
Jan 26 14:21:52: ERROR: CC: PID:*=1 PID:*=1 PID:*=1 
Jan 26 14:30:52: ERROR: CC: PID:*=1 PID:*=1 PID:*=1 PID:*=1 PID:*=1 PID:*=1 
Jan 26 14:45:52: ERROR: CC: PID:*=1 PID:*=1 PID:*=1 PID:*=1 PID:*=1 
Jan 26 14:48:52: ERROR: CC: PID:*=1 PID:*=1 PID:*=1 
Jan 26 14:57:53: ERROR: CC: PID:*=1 PID:*=1 PID:*=1 PID:*=1 PID:*=1 PID:*=1

При этом судя по графикам мультикаста с портов свитчей трафик регулярно переезжает с порта на порт в LACP на 4 и больше портах хотя в потоке никаких изменений src/dst ip/port нету. Выключить балансировку мультикаста свитч Force10 S4810 не позволяет.

Примечательно что ошибки возникают секунда-в-секунду с интервалом кратным 3 минутам. Подозреваю что ошибки возникают как раз из-за регулярных попыток свитча перебалансировать мультикаст трафик (с сервера поток приходит без ошибок).

[Butch3r]

Да, у меня CC происходит через LACP имеено из-за неправильной последовательности пакетов.

 

То, что вы пишите про force10 - немного другой случай.

[zhenya`]

Странно.. обычно мультик на длинке в лаге льётся в один порт и проблем нет

[pppoetest]

У меня ~ равномерно размазывается на 3 порта, суммарно до 800мбит, рассыпухи незамечено.

[Butch3r]

У меня ~ равномерно размазывается на 3 порта, суммарно до 800мбит, рассыпухи незамечено.

а у меня 1500 в 2. И вот тут они есть. Но, Я повторюсь - зависит от сжатия мультикаста. Сыпятся только определенные товарыканалы )))).

Но так как это междугородний канал то нет возможности просто так его увеличить, придётся доплачивать.

При этом на тест включали 10г - рассыпания полностью уходят

[pppoetest]

При этом на тест включали 10г - рассыпания полностью уходят

Одной соской? Без ласпа?

[Butch3r]

При этом на тест включали 10г - рассыпания полностью уходят

Одной соской? Без ласпа?

да

[undro]

Странно..

Во-во.

На SNR CC ошибок нет (0-10шт за сутки). Хотя к нему потоки прилетают по 3x10G от железки магистрала.

Между городами lacp через транспорт других магистралов. Гоняем 1G+ мультика туда (~200 каналов). Размазывается ровно. Проблемы нет.

 

P.S. Перенесли заказ на одиночный линк. Наблюдаем.

[pers123]

это не потери/ошибки на транспорте, это packet reordering, HD stream на определенных кодеках очень чувствительны к нему.

packet reordering на LAG явление достаточно частое, особенно если никаких QoS рулов не прописано.

балансировка src/dst ip для мультикаста все равно будет для каждого канала выдавать всегда один и тот же хеш,

то есть один стрим будет ложится в один и тот же линк, но буфер этого линка все равно перетряхивается под другой трафик

Можно попробовать вариант пустить мультикаст, как EF, по идее, для EF дeйствует strict priority в буфере интерфейса,

это минимизирует вероятность packet reordering.

[zstas]

гоняем мультикаст по разным ченелам 2х1, 3х1, 2х10. нигде не было таких проблем.

возможно проблемы из-за маленького буфера у вашего свича.

 

правильно советуют - нужно красить мультикаст и пихать его в strict priority.

[Butch3r]

гоняем мультикаст по разным ченелам 2х1, 3х1, 2х10. нигде не было таких проблем.

возможно проблемы из-за маленького буфера у вашего свича.

 

правильно советуют - нужно красить мультикаст и пихать его в strict priority.

сколько % в этих линках мультикаста? У меня 1.5г из 2 это мультикаст и в этом линке нет ничего кроме него. И всё равно реордеринг включается. Свич - 3750G с одной стороны, HP A5500 с другой.

 

Подскажите как жестно настроить QOS, у меня сейчас траст dscp на порту написан и всё.

 

 

Ещё адская штука у свичей это HOL. С ним сыпится просто жесть, но оно как бы и понятно почему.

Изменено 2 февраля, 2017 пользователем Butch3r

[zstas]

сколько % в этих линках мультикаста?

по разному. где то 100%, где то 5-10%.

 

на hp\h3c 5500 можно принудительно включить strict priority на порту

[sysname] interface gigabitethernet 1/0/1 
[sysname-GigabitEthernet1/0/1] qos sp 

если там кроме мультикаста бегает еще best effort траффик - тогда надо красить, либо acl, либо делать trust чему-нибудь. потом врубайте qos wrr и выберите для нужных очередей strict priority.

http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5195279&docId=emr_na-c03180138&docLocale=en_US

[pers123]

гоняем мультикаст по разным ченелам 2х1, 3х1, 2х10. нигде не было таких проблем.

возможно проблемы из-за маленького буфера у вашего свича.

 

правильно советуют - нужно красить мультикаст и пихать его в strict priority.

сколько % в этих линках мультикаста? У меня 1.5г из 2 это мультикаст и в этом линке нет ничего кроме него. И всё равно реордеринг включается. Свич - 3750G с одной стороны, HP A5500 с другой.

А какой из свичей со стороны источника, выше по течению?

Мультикаст-то в одну сторону бежит.

[v_r]

Подскажите как жестно настроить QOS, у меня сейчас траст dscp на порту написан и всё.

Для покраски трафика на сети я использую COS потому что в IPv6 распознают не все свитчи и соответственно покрасить его не могут, а MPLS EXP распознает вообще мало оборудования.

По DSCP имеет смысл красить трафик в корпоративной сети где есть доверие к абонентским ПК и серверам, либо можно написать свои более-менее одинаковые правила для них. В сети провайдера доверять DSCP абонентского трафика рискованно. Поэтому весь абонентский трафик я крашу в COS 0 и пускаю в самую низкоприоритетную очередь. Мультикаст крашу в COS4 при помощи ACL на входе потока, и везде настроена strict priority для этого COS. Ошибок на мультикасте (помимо проблемы с периодической перебалансировкой на свитчах) действительно практически нет. В идеале нужно на всем оборудовании магистральной сети настроить одинаковые правила QoS чтобы трафик трактовался одинаково, да и поддерживать это проще: в ядре сети на всех портах стоит Trust COS, назначение COS производится на портах в сторону аплинков/абонентов/серверов. Но если нужно приоритизировать трафик на 1-2 линках то проще настроить QoS только проблемном оборудовании с минимумом изменений.

 

И перед настройкой QoS надо понимать возможности оборудования и настройки по умолчанию, вот тут полный бардак. На D-Link и Alcatel по умолчанию все очереди strict priority и включен Trust COS или DSCP, на свитчах других производителей по умолчанию очереди Round-Robin но Trust выключен (Force10, Catalyst, Nexus); на каком-то оборудовании 4 очереди на порт, на каком-то 8 очередей, на N3K 8 очередей для юникаста и 4 для мультикаста; на каком-то оборудовании можно несколько очередей сделать strict priority (например для IPTV и голоса) на каком-то strict может быть только одна очередь, и т.д.

 

Можно попробовать вариант пустить мультикаст, как EF, по идее, для EF дeйствует strict priority в буфере интерфейса,

это минимизирует вероятность packet reordering.

На Catalyst 3750 при включении QoS и настройках по умолчанию очередь трафика с EF шейпится в 25% скорости порта, так что покраска в EF без понимания настроек оборудования может навредить.

[Ivan_83]

Я бы первым делом на свиче отключил игмп снупинг: почему то начинает сыпать когда мультикаст льётся на несколько портов при снупинге.

LACP не раундробином пакеты раскидывает (и к сожалению и к счастью) а на основании хэша от dst мака, те один и тот же мультикаст поток всегда идёт одним путём.

 

Ну и ещё.

Если вы там упёрлись сверху в гигабит то скорее всего вы ещё не поняли что наступили на грабли: у многих свичей лимит на мультикаст группы 128/256.

128 это сколько снупинг может, а всё что от 128 до 256 идёт уже без снупинга.

А всё что в 256 не слезло - дропается. Притом оно периодически выкидывает кого то из первых 256 и встаёт вместо него, в итоге подсыпается всё. Активность подсыпания зависит от того сколько каналов в 256 не влезло.

 

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

[zstas]

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

Ага, а если взять циску, с включенным по умолчанию WRR, где при попадании всего трафика в одну очередь будем получать картинку, что начинает уже работать RED\WRED при загрузке порта 80%.

[Ivan_83]

Так не берите кошек.

[Butch3r]

гоняем мультикаст по разным ченелам 2х1, 3х1, 2х10. нигде не было таких проблем.

возможно проблемы из-за маленького буфера у вашего свича.

 

правильно советуют - нужно красить мультикаст и пихать его в strict priority.

сколько % в этих линках мультикаста? У меня 1.5г из 2 это мультикаст и в этом линке нет ничего кроме него. И всё равно реордеринг включается. Свич - 3750G с одной стороны, HP A5500 с другой.

А какой из свичей со стороны источника, выше по течению?

Мультикаст-то в одну сторону бежит.

С HP на 3750. Между ними PIM.

 

Подскажите как жестно настроить QOS, у меня сейчас траст dscp на порту написан и всё.

Для покраски трафика на сети я использую COS потому что в IPv6 распознают не все свитчи и соответственно покрасить его не могут, а MPLS EXP распознает вообще мало оборудования.

По DSCP имеет смысл красить трафик в корпоративной сети где есть доверие к абонентским ПК и серверам, либо можно написать свои более-менее одинаковые правила для них. В сети провайдера доверять DSCP абонентского трафика рискованно. Поэтому весь абонентский трафик я крашу в COS 0 и пускаю в самую низкоприоритетную очередь. Мультикаст крашу в COS4 при помощи ACL на входе потока, и везде настроена strict priority для этого COS. Ошибок на мультикасте (помимо проблемы с периодической перебалансировкой на свитчах) действительно практически нет. В идеале нужно на всем оборудовании магистральной сети настроить одинаковые правила QoS чтобы трафик трактовался одинаково, да и поддерживать это проще: в ядре сети на всех портах стоит Trust COS, назначение COS производится на портах в сторону аплинков/абонентов/серверов. Но если нужно приоритизировать трафик на 1-2 линках то проще настроить QoS только проблемном оборудовании с минимумом изменений.

 

И перед настройкой QoS надо понимать возможности оборудования и настройки по умолчанию, вот тут полный бардак. На D-Link и Alcatel по умолчанию все очереди strict priority и включен Trust COS или DSCP, на свитчах других производителей по умолчанию очереди Round-Robin но Trust выключен (Force10, Catalyst, Nexus); на каком-то оборудовании 4 очереди на порт, на каком-то 8 очередей, на N3K 8 очередей для юникаста и 4 для мультикаста; на каком-то оборудовании можно несколько очередей сделать strict priority (например для IPTV и голоса) на каком-то strict может быть только одна очередь, и т.д.

 

Можно попробовать вариант пустить мультикаст, как EF, по идее, для EF дeйствует strict priority в буфере интерфейса,

это минимизирует вероятность packet reordering.

На Catalyst 3750 при включении QoS и настройках по умолчанию очередь трафика с EF шейпится в 25% скорости порта, так что покраска в EF без понимания настроек оборудования может навредить.

мы стремимся к одному вендору, поэтому взгляд пал на dscp.

 

Я бы первым делом на свиче отключил игмп снупинг: почему то начинает сыпать когда мультикаст льётся на несколько портов при снупинге.

LACP не раундробином пакеты раскидывает (и к сожалению и к счастью) а на основании хэша от dst мака, те один и тот же мультикаст поток всегда идёт одним путём.

 

Ну и ещё.

Если вы там упёрлись сверху в гигабит то скорее всего вы ещё не поняли что наступили на грабли: у многих свичей лимит на мультикаст группы 128/256.

128 это сколько снупинг может, а всё что от 128 до 256 идёт уже без снупинга.

А всё что в 256 не слезло - дропается. Притом оно периодически выкидывает кого то из первых 256 и встаёт вместо него, в итоге подсыпается всё. Активность подсыпания зависит от того сколько каналов в 256 не влезло.

 

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

Ну опять же 128/256 это на древних свичах. Я стремлюсь до кластеров тащить по PIM, а там уже раздавать на свичи доступа.