Jump to content

Recommended Posts

Posted

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

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

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

Posted

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

Posted

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

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

Posted

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

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

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

Posted

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

Posted

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

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

Posted

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

Posted

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

Posted

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

Posted

shicoy

 

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

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

Posted

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

Posted

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

 

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

Posted

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

Posted

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

 

 

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

 

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

Posted

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

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

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

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

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

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

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

Posted

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

 

 

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

Posted

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

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

 

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

Posted (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 by 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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.