shicoy Posted March 26, 2012 Posted March 26, 2012 Есть такая проблема, по сети распостраняется мультикаст, QoS в сети настроен, мультику присваивается dscp = 40, cos = 5, сниф показывает что приоритезация до доступа долетает. Однако TSreader показывает Continuity Error порядка 10-15 на 1000 пакетов. Т.е. есть подозрение что все таки где-то в сети дропаются udp пакеты, вопрос какими еще средствами можно отдиагностировать поток и выяснить на каком участке проблемы? Вставить ник Quote
s.lobanov Posted March 26, 2012 Posted March 26, 2012 Для начала нарисовать графики загрузки(rx/tx/errors/drops) всех портов, через которые проходит трафик. Если полок и ошибок/полок нет, софтроутеров на пути тоже нет, то исправит только бубен, если же где-то полки, то вставать анализатором до и после этого порта. Вставить ник Quote
shicoy Posted March 27, 2012 Author Posted March 27, 2012 Загрузка каналов, наличие ошибок, все уже было проверено неоднократно. Видимо бубен нужен. :(((( Вставить ник Quote
s.lobanov Posted March 27, 2012 Posted March 27, 2012 А балансировки трафика по двум линкам нигде нет? Возможно, пакеты приходят в "неправильном" порядке, что увеличивает каунтер Continuity Error Перемешивание может происходить как на L2(lacp и т.п.), так и на L3. Права L3 балансинг сейчас почти всегда per-flow, но всё же. Вставить ник Quote
shicoy Posted March 27, 2012 Author Posted March 27, 2012 У меня тоже подозрение что именно сбивается последовательность пакетов, но ни LACP и L3 балансировки нет (точнее L3 есть, но т.к. используется PIM-SM для маршрутизации, то трафик по идее всегда идет через один физический линк). Хотя Qos Mechanism установлен в strict Возможно существуют условно-бесплатные анализаторы проверки последовательности пакетов. Вставить ник Quote
s.lobanov Posted March 27, 2012 Posted March 27, 2012 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), чтобы он попадал в те же очереди, что и мультикаст Вставить ник Quote
shicoy Posted March 28, 2012 Author Posted March 28, 2012 ~# 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 Порядок следования пакетов все таки нарушается. Осталось понять причину, а тут видимо уже без бубна не обойтись. Вставить ник Quote
s.lobanov Posted March 28, 2012 Posted March 28, 2012 2 датаграмы это не показательно, лучше провести тест хотя бы на часик Вставить ник Quote
SergeiK Posted March 28, 2012 Posted March 28, 2012 А QoS как настроен? Если используется bandwidth, а не strict priority, то он допускает перемешивание трафика. Вставить ник Quote
shicoy Posted March 29, 2012 Author Posted March 29, 2012 Везде в strict, QoS использует разумеется приоритет по очередям, iptv маскируем в dscp=40, на коммутаторах проверяется метка и выставляется класс обслуживания. Вставить ник Quote
Globus Posted March 29, 2012 Posted March 29, 2012 Поток записывали? Потеря 1 IP пакета означает, что пропадут все пакеты TS, что вложены в IP - 7, 6 , 5 - как настроен стример. Может у вас уже на входе потери? Вставить ник Quote
shicoy Posted March 29, 2012 Author Posted March 29, 2012 Однозначно дело не в стримере, пробовал через vlc даже отдавать мультикастом фильм, все равно идут Continuity Error, как вариант остается лазить по сети и цепляться к разным сегментам, отдавая контрольный файл через vlc и искать узкое место. Вставить ник Quote
s.lobanov Posted March 29, 2012 Posted March 29, 2012 shicoy А на самом-то деле картинка сыпется? Вставить ник Quote
shicoy Posted March 29, 2012 Author Posted March 29, 2012 shicoy А на самом-то деле картинка сыпется? Иногда. Вобщем как показали последние опыты, проблема в длинках. Если на доступе распихивать пакеты по очередям через Acl то все хорошо, если средствами mapping (как по идее оно правильнее) то бардак. Ждем фикса. Вставить ник Quote
s.lobanov Posted March 29, 2012 Posted March 29, 2012 Т.е. трафик не дропается, но перемешивается на длинковском аксессе? Вставить ник Quote
shicoy Posted March 29, 2012 Author Posted March 29, 2012 По всей видимости да. Завтра еще пару тестов сделаем с разными моделями ( в тч не длинк) по результатам отпишусь Вставить ник Quote
martini Posted March 29, 2012 Posted March 29, 2012 ждем результатов, версии прошивок на которых проводились тесты тоже укажите Вставить ник Quote
Genn Posted April 6, 2012 Posted April 6, 2012 По всей видимости да. Завтра еще пару тестов сделаем с разными моделями ( в тч не длинк) по результатам отпишусь Перемешивание на доступе подтвердилось? Вставить ник Quote
shicoy Posted April 6, 2012 Author Posted April 6, 2012 Пока не могу дать точный комментарий, несколько напрягли другие дела. Как закончу тесты отпишусь. Вставить ник Quote
dmvy Posted April 9, 2012 Posted April 9, 2012 а на транзитных коммутаторах настроено доверие к dscp и cos? на dlink необходимо принудительно сделать маппинг dscp. иначе он на них прибор кладет. Вставить ник Quote
eddy_mut Posted April 9, 2012 Posted April 9, 2012 У нас на длинках ацл такого вида 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. Вроде все сделано по мануалам, ан нет время от времени подсыпает, по вечерам в часы пиковой нагрузки. Вот и думается а не в агрегации ли портов дело? Вставить ник Quote
shicoy Posted April 9, 2012 Author Posted April 9, 2012 а на транзитных коммутаторах настроено доверие к dscp и cos? на dlink необходимо принудительно сделать маппинг dscp. иначе он на них прибор кладет. На транзите стоят DGS3627G на них нет dscp_mapping, там ACL рулим. Сейчас на стенде исключил DGS, теперь выглядит так: Стример <-> Foundry BI4000 <-> DES3200-28 <-> Клиент Ошибки есть, примерно 1 на 1000 пакетов. Анализатор подключенный к стримеру ошибок не выдает. на Foundry настройки qos тоже сделаны. Вставить ник Quote
shicoy Posted April 9, 2012 Author Posted April 9, 2012 У нас на длинках ацл такого вида 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 ? Или какие у вас адреса м-групп каналов? Вставить ник Quote
eddy_mut Posted April 9, 2012 Posted April 9, 2012 У нас адреса 234.5.x.x Маска 255.0.0.0 охватывает весь мультикаст диапазон 224.0.0.0 (с запасом на будущее :) Примеры ацл брал у суппорта длинка. Вставить ник Quote
eddy_mut Posted April 12, 2012 Posted April 12, 2012 (edited) Поправили ацл. Оказывается трафик надо было красить на входящих портах а не исходящих. 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 April 12, 2012 by eddy_mut Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.