Перейти к содержимому
Калькуляторы

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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), чтобы он попадал в те же очереди, что и мультикаст

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

~# 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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

shicoy

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

shicoy

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Т.е. трафик не дропается, но перемешивается на длинковском аксессе?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По всей видимости да. Завтра еще пару тестов сделаем с разными моделями ( в тч не длинк) по результатам отпишусь

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По всей видимости да. Завтра еще пару тестов сделаем с разными моделями ( в тч не длинк) по результатам отпишусь

 

Перемешивание на доступе подтвердилось?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пока не могу дать точный комментарий, несколько напрягли другие дела. Как закончу тесты отпишусь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

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. Вроде все сделано по мануалам, ан нет время от времени подсыпает, по вечерам в часы пиковой нагрузки.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

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 ? Или какие у вас адреса м-групп каналов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

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

Изменено пользователем eddy_mut

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.