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

Проверка QoS или сыпеться мультикаст

Есть такая проблема, по сети распостраняется мультикаст, QoS в сети настроен, мультику присваивается dscp = 40, cos = 5, сниф показывает что приоритезация до доступа долетает.

Однако TSreader показывает Continuity Error порядка 10-15 на 1000 пакетов.

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

Share this post


Link to post
Share on other sites

Для начала нарисовать графики загрузки(rx/tx/errors/drops) всех портов, через которые проходит трафик. Если полок и ошибок/полок нет, софтроутеров на пути тоже нет, то исправит только бубен, если же где-то полки, то вставать анализатором до и после этого порта.

Share this post


Link to post
Share on other sites

Загрузка каналов, наличие ошибок, все уже было проверено неоднократно. Видимо бубен нужен. :((((

Share this post


Link to post
Share on other sites

А балансировки трафика по двум линкам нигде нет? Возможно, пакеты приходят в "неправильном" порядке, что увеличивает каунтер Continuity Error

Перемешивание может происходить как на L2(lacp и т.п.), так и на L3. Права L3 балансинг сейчас почти всегда per-flow, но всё же.

Share this post


Link to post
Share on other sites

У меня тоже подозрение что именно сбивается последовательность пакетов, но ни LACP и L3 балансировки нет (точнее L3 есть, но т.к. используется PIM-SM для маршрутизации, то трафик по идее всегда идет через один физический линк).

Хотя Qos Mechanism установлен в strict

Возможно существуют условно-бесплатные анализаторы проверки последовательности пакетов.

Share this post


Link to post
Share on other sites

iperf умеет. Собрал мини-стенд:

192.168.1.100(iperf -u -c 192.168.1.128)<->192.168.1.128(iperf -u -s)

 

на генераторе трафика(192.168.1.100) вношу случайную задержку для каждого пакета(чтобы они перемешивались):

tc qdisc add dev eth0 root netem delay 1ms 20ms

 

После чего iperf показывает:

[ 3] Server Report:

[ 3] 0.0- 5.0 sec 642 KBytes 1.05 Mbits/sec 7.004 ms 65/ 447 (15%)

[ 3] 0.0- 5.0 sec 65 datagrams received out-of-order

 

В вашем случае трафик ещё нужно покрасить(либо на сетевом оборудовании, либо с помощью iptables), чтобы он попадал в те же очереди, что и мультикаст

Share this post


Link to post
Share on other sites

~# iperf -u -c xxx.xxx.xxx.2 -b 10240K  -t 600 -i 30
------------------------------------------------------------
Client connecting to xxx.xxx.xxx.2, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  124 KByte (default)
------------------------------------------------------------
[  3] local xxx.xxx.xxx.23 port 45672 connected with xxx.xxx.xxx.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 30.0-60.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 60.0-90.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 90.0-120.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 120.0-150.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 150.0-180.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 180.0-210.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 210.0-240.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 240.0-270.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 270.0-300.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 300.0-330.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 330.0-360.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 360.0-390.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 390.0-420.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 420.0-450.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 450.0-480.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 480.0-510.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 510.0-540.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 540.0-570.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3] 570.0-600.0 sec  36.6 MBytes  10.2 Mbits/sec
[  3]  0.0-600.0 sec   733 MBytes  10.2 Mbits/sec
[  3] Sent 522649 datagrams
[  3] Server Report:
[  3]  0.0-599.8 sec   733 MBytes  10.2 Mbits/sec   0.363 ms    1/522648 (0.00019%)
[  3]  0.0-599.8 sec  2 datagrams received out-of-order

Порядок следования пакетов все таки нарушается. Осталось понять причину, а тут видимо уже без бубна не обойтись.

Share this post


Link to post
Share on other sites

2 датаграмы это не показательно, лучше провести тест хотя бы на часик

Share this post


Link to post
Share on other sites

А QoS как настроен? Если используется bandwidth, а не strict priority, то он допускает перемешивание трафика.

Share this post


Link to post
Share on other sites

Везде в strict, QoS использует разумеется приоритет по очередям, iptv маскируем в dscp=40, на коммутаторах проверяется метка и выставляется класс обслуживания.

Share this post


Link to post
Share on other sites

Поток записывали? Потеря 1 IP пакета означает, что пропадут все пакеты TS, что вложены в IP - 7, 6 , 5 - как настроен стример. Может у вас уже на входе потери?

Share this post


Link to post
Share on other sites

Однозначно дело не в стримере, пробовал через vlc даже отдавать мультикастом фильм, все равно идут Continuity Error, как вариант остается лазить по сети и цепляться к разным сегментам, отдавая контрольный файл через vlc и искать узкое место.

Share this post


Link to post
Share on other sites

shicoy

 

А на самом-то деле картинка сыпется?

Иногда. Вобщем как показали последние опыты, проблема в длинках. Если на доступе распихивать пакеты по очередям через Acl то все хорошо, если средствами mapping (как по идее оно правильнее) то бардак. Ждем фикса.

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

ждем результатов, версии прошивок на которых проводились тесты тоже укажите

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

а на транзитных коммутаторах настроено доверие к dscp и cos? на dlink необходимо принудительно сделать маппинг dscp. иначе он на них прибор кладет.

Share this post


Link to post
Share on other sites

У нас на длинках ацл такого вида

 

 

create access_profile profile_id 1 ip vlan destination_ip_mask 255.0.0.0 

config access_profile profile_id 1 add access_id 1 ip vlan multi-cas destination_ip 224.0.0.0  port 19-20 permit priority 5 replace_priority replace_dscp 48

 

Коммутатор DGS-3627G

В него втыкаются стримера. Порты 19-20 аплинк в коммутатор ядра, соответственно, в LACP. Вроде все сделано по мануалам, ан нет время от времени подсыпает, по вечерам в часы пиковой нагрузки.

 

Вот и думается а не в агрегации ли портов дело?

Share this post


Link to post
Share on other sites

а на транзитных коммутаторах настроено доверие к dscp и cos? на dlink необходимо принудительно сделать маппинг dscp. иначе он на них прибор кладет.

На транзите стоят DGS3627G на них нет dscp_mapping, там ACL рулим.

Сейчас на стенде исключил DGS, теперь выглядит так:

Стример <-> Foundry BI4000 <-> DES3200-28 <-> Клиент

Ошибки есть, примерно 1 на 1000 пакетов.

Анализатор подключенный к стримеру ошибок не выдает.

на Foundry настройки qos тоже сделаны.

Share this post


Link to post
Share on other sites

У нас на длинках ацл такого вида

 

 

create access_profile profile_id 1 ip vlan destination_ip_mask 255.0.0.0 

config access_profile profile_id 1 add access_id 1 ip vlan multi-cas destination_ip 224.0.0.0  port 19-20 permit priority 5 replace_priority replace_dscp 48

 

Коммутатор DGS-3627G

В него втыкаются стримера. Порты 19-20 аплинк в коммутатор ядра, соответственно, в LACP. Вроде все сделано по мануалам, ан нет время от времени подсыпает, по вечерам в часы пиковой нагрузки.

 

Вот и думается а не в агрегации ли портов дело?

 

А почему в правиле маска 255.0.0.0 а не 224.0.0.0 ? Или какие у вас адреса м-групп каналов?

Share this post


Link to post
Share on other sites

У нас адреса 234.5.x.x

Маска 255.0.0.0 охватывает весь мультикаст диапазон 224.0.0.0 (с запасом на будущее :)

 

Примеры ацл брал у суппорта длинка.

Share this post


Link to post
Share on other sites

Поправили ацл. Оказывается трафик надо было красить на входящих портах а не исходящих.

 

 

create access_profile profile_id 1 ip vlan destination_ip_mask 240.0.0.0 

config access_profile profile_id 1 add access_id 1 ip vlan video destination_ip 224.0.0.0  port 9 permit priority 5 replace_priority replace_dscp 48

Edited by eddy_mut

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