shicoy Опубликовано 26 марта, 2012 · Жалоба Есть такая проблема, по сети распостраняется мультикаст, QoS в сети настроен, мультику присваивается dscp = 40, cos = 5, сниф показывает что приоритезация до доступа долетает. Однако TSreader показывает Continuity Error порядка 10-15 на 1000 пакетов. Т.е. есть подозрение что все таки где-то в сети дропаются udp пакеты, вопрос какими еще средствами можно отдиагностировать поток и выяснить на каком участке проблемы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 26 марта, 2012 · Жалоба Для начала нарисовать графики загрузки(rx/tx/errors/drops) всех портов, через которые проходит трафик. Если полок и ошибок/полок нет, софтроутеров на пути тоже нет, то исправит только бубен, если же где-то полки, то вставать анализатором до и после этого порта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 27 марта, 2012 · Жалоба Загрузка каналов, наличие ошибок, все уже было проверено неоднократно. Видимо бубен нужен. :(((( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 27 марта, 2012 · Жалоба А балансировки трафика по двум линкам нигде нет? Возможно, пакеты приходят в "неправильном" порядке, что увеличивает каунтер Continuity Error Перемешивание может происходить как на L2(lacp и т.п.), так и на L3. Права L3 балансинг сейчас почти всегда per-flow, но всё же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 27 марта, 2012 · Жалоба У меня тоже подозрение что именно сбивается последовательность пакетов, но ни LACP и L3 балансировки нет (точнее L3 есть, но т.к. используется PIM-SM для маршрутизации, то трафик по идее всегда идет через один физический линк). Хотя Qos Mechanism установлен в strict Возможно существуют условно-бесплатные анализаторы проверки последовательности пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 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), чтобы он попадал в те же очереди, что и мультикаст Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 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 Порядок следования пакетов все таки нарушается. Осталось понять причину, а тут видимо уже без бубна не обойтись. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 28 марта, 2012 · Жалоба 2 датаграмы это не показательно, лучше провести тест хотя бы на часик Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 28 марта, 2012 · Жалоба А QoS как настроен? Если используется bandwidth, а не strict priority, то он допускает перемешивание трафика. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 29 марта, 2012 · Жалоба Везде в strict, QoS использует разумеется приоритет по очередям, iptv маскируем в dscp=40, на коммутаторах проверяется метка и выставляется класс обслуживания. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Globus Опубликовано 29 марта, 2012 · Жалоба Поток записывали? Потеря 1 IP пакета означает, что пропадут все пакеты TS, что вложены в IP - 7, 6 , 5 - как настроен стример. Может у вас уже на входе потери? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 29 марта, 2012 · Жалоба Однозначно дело не в стримере, пробовал через vlc даже отдавать мультикастом фильм, все равно идут Continuity Error, как вариант остается лазить по сети и цепляться к разным сегментам, отдавая контрольный файл через vlc и искать узкое место. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 29 марта, 2012 · Жалоба shicoy А на самом-то деле картинка сыпется? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 29 марта, 2012 · Жалоба shicoy А на самом-то деле картинка сыпется? Иногда. Вобщем как показали последние опыты, проблема в длинках. Если на доступе распихивать пакеты по очередям через Acl то все хорошо, если средствами mapping (как по идее оно правильнее) то бардак. Ждем фикса. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 29 марта, 2012 · Жалоба Т.е. трафик не дропается, но перемешивается на длинковском аксессе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 29 марта, 2012 · Жалоба По всей видимости да. Завтра еще пару тестов сделаем с разными моделями ( в тч не длинк) по результатам отпишусь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 29 марта, 2012 · Жалоба ждем результатов, версии прошивок на которых проводились тесты тоже укажите Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Genn Опубликовано 6 апреля, 2012 · Жалоба По всей видимости да. Завтра еще пару тестов сделаем с разными моделями ( в тч не длинк) по результатам отпишусь Перемешивание на доступе подтвердилось? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 6 апреля, 2012 · Жалоба Пока не могу дать точный комментарий, несколько напрягли другие дела. Как закончу тесты отпишусь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 9 апреля, 2012 · Жалоба а на транзитных коммутаторах настроено доверие к dscp и cos? на dlink необходимо принудительно сделать маппинг dscp. иначе он на них прибор кладет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eddy_mut Опубликовано 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. Вроде все сделано по мануалам, ан нет время от времени подсыпает, по вечерам в часы пиковой нагрузки. Вот и думается а не в агрегации ли портов дело? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 9 апреля, 2012 · Жалоба а на транзитных коммутаторах настроено доверие к dscp и cos? на dlink необходимо принудительно сделать маппинг dscp. иначе он на них прибор кладет. На транзите стоят DGS3627G на них нет dscp_mapping, там ACL рулим. Сейчас на стенде исключил DGS, теперь выглядит так: Стример <-> Foundry BI4000 <-> DES3200-28 <-> Клиент Ошибки есть, примерно 1 на 1000 пакетов. Анализатор подключенный к стримеру ошибок не выдает. на Foundry настройки qos тоже сделаны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 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 ? Или какие у вас адреса м-групп каналов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eddy_mut Опубликовано 9 апреля, 2012 · Жалоба У нас адреса 234.5.x.x Маска 255.0.0.0 охватывает весь мультикаст диапазон 224.0.0.0 (с запасом на будущее :) Примеры ацл брал у суппорта длинка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
eddy_mut Опубликовано 12 апреля, 2012 (изменено) · Жалоба Поправили ацл. Оказывается трафик надо было красить на входящих портах а не исходящих. 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 Изменено 12 апреля, 2012 пользователем eddy_mut Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...