[Aksel]

Добрый вечер!

Никак не могу победить, приоритезацию трафика на коммутаторах D-link 3200-28 rev C1.

Имею более 1000 данных коммутаторов, в связи с вводом в эксплуатацию тарифа "Безлимит - 100 мегабит", появились множественные обращения в техпо, с рассыпающимся ТВ, т.к. канал забивают торрентами.

 

На выходе(источник) multicast весь красится в dscp 63.

 

На REV A/B победил это все дело очень легко:

 

create access_profile  ip  destination_ip 224.0.0.0  profile_id 4
config access_profile profile_id 4  add access_id 1  ip  destination_ip 224.0.0.0  port 25-26 permit priority 7 counter enable

 

А вот на С1, такая фича работать не хочет категорически. Шел двумя путями.

1) Использование функционала dscp trust:

 

config dscp trust 25-26 state enable
config scheduling_mechanism ports 1-28 strict
config scheduling ports 1-28 0 weight 1
config scheduling ports 1-28 1 weight 2
config scheduling ports 1-28 2 weight 3
config scheduling ports 1-28 3 weight 4
config scheduling ports 1-28 4 weight 5
config scheduling ports 1-28 5 weight 6
config scheduling ports 1-28 6 weight 7
config scheduling ports 1-28 7 weight 8
config scheduling_mechanism strict

2) Использование ACL и поднятие приоритета:

create access_profile profile_id 12 profile_name DSCP ip destination_ip_mask 224.0.0.0
config access_profile profile_id 12 add access_id 1 ip destination_ip 224.0.0.0 port 25-26 permit priority 7 counter enable

 

При этом хочу заметить, что при выключенном функционале (1 или 2), картинка сыпится просто ужасно, если включаю одно из двух, начинает работать более менее, но фризы наблюдаются каждые 10-15 секунд, что конечно же так же не позволяет смотреть IPTV.

Прошивки перепроверил вроде бы уже все, что были (а их было около 17).

 

 

config igmp_snooping multicast_vlan_group_profile VLAN31 add 225.3.1.1-225.3.1.255
create igmp_snooping multicast_vlan TV 31
config igmp_snooping multicast_vlan TV state enable replace_source_ip 0.0.0.0
config igmp_snooping multicast_vlan TV add member_port 1-24,27-28
config igmp_snooping multicast_vlan TV add tag_member_port 25-26
config igmp_snooping multicast_vlan_group TV add profile_name VLAN31

create mcast_filter_profile profile_id 1 profile_name iptv
config mcast_filter_profile profile_id 1 add 225.3.1.1-225.3.1.255
config limited_multicast_addr ports 1-24 add profile_id 1
config limited_multicast_addr ports 1-24 access permit
config max_mcast_group ports 1-24 max_group 20

config multicast vlan_filtering_mode vlanid 31 filter_unregistered_groups

config igmp_snooping vlan_name TV fast_leave enable report_suppression enable
config igmp_snooping querier vlan_name TV query_interval 125  max_response_time 10 robustness_variable 2 last_member_query_interval 1 state disable version 3
config igmp_snooping data_driven_learning vlan_name TV expiry_time 10 state enable aged_out enable

 

 

Кто смог добиться правильной работы функционала приоретизирования трафика?

[pppoetest]

Смысл красить мультикаст на доступе, если пакеты уже пришли? Это тоже самое, что шейпировать входящий трафик. Красьте у источника, и будет вам счастье. На агрегации и доступе я всего лишь сохраняю покраску с аплинков, а на источнике:

create access_profile profile_id 1 profile_name 1 ip destination_ip_mask 240.0.0.0

config access_profile profile_id 1 add access_id 1 ip destination_ip 224.0.0.0 port 1-28 permit priority 5 replace_priority urpf_state_check enable

[s.lobanov]

Пишу со смарта, проверить не могу. Но вроде как тупой траст это правильно, а dscp 63 просто мапируется в нулевую очередь, а не в 7ую. Проверьте dscp-...-priority map

 

Обычно 63 не используют, а юзают 56(EF) или CS5

[vurd]

А не cs4 разве?

 

По дефолту с cs5 длинки бьют пакеты сильней чем без какой-либо приоритезации.

[Aksel]

Смысл красить мультикаст на доступе, если пакеты уже пришли? Это тоже самое, что шейпировать входящий трафик. Красьте у источника, и будет вам счастье. На агрегации и доступе я всего лишь сохраняю покраску с аплинков, а на источнике:

create access_profile profile_id 1 profile_name 1 ip destination_ip_mask 240.0.0.0

config access_profile profile_id 1 add access_id 1 ip destination_ip 224.0.0.0 port 1-28 permit priority 5 replace_priority urpf_state_check enable

Добрый день. Вы читаете не внимательно. Я же писал, что dscp trust не отрабатывает должным образом. Поэтому пошел искать обходные пути.

 

Пишу со смарта, проверить не могу. Но вроде как тупой траст это правильно, а dscp 63 просто мапируется в нулевую очередь, а не в 7ую. Проверьте dscp-...-priority map

 

Обычно 63 не используют, а юзают 56(EF) или CS5

Вы не правы. 63 это максимальный приоритет, даже в default настройках свитча:

 

config dscp map all dscp_priority 56-63 to 7

[Negator]

По дефолту с cs5 длинки бьют пакеты сильней чем без какой-либо приоритезации.

это откуда такие данные?

[Aksel]

EF - dscp 46

CS5 - dscp 40

CS4 - dscp 32

[darkagent]

если не хотите ломать голову с маркировкой, то

config scheduling_mechanism strict 

- поменяйте на wrr, сразу станет легче.

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

детальная настройка потребуется разве что если транзитная утилизация коммутатора превысит 50%

 

что до красок, то есть различные best-practice, одни более древние, другие более свежие.

у себя крашу (в ядре) так:

igmp - cs3

pim - af31

mcast - cs4

snmp - cs2

[Aksel]

- поменяйте на wrr, сразу станет легче.

Пробовал, не помогает.

 

Еще раз повторюсь, что данная проблема только на rev.C1, и только при загрузке порта торрентами.

[Aksel]

Залил видео, чтобы было нагляднее. Уже не использовал TS Reader, а просто torrent+IPTV player.

Надеюсь будет понятно, как отрабатывает 3200-28 A/B и 3200 C1.

 

3200-28 A/B

http://vimple.co/9650fc68261041deaa79ba84c260cebb

 

3200-28 C1

http://vimple.co/b77c018596714b15b883199536682974

 

 

Что скажете?

[m4a12345]

Я сам дома когда смотрю иптв и, например меряю скорость спидтестом, иптв сыпит. Думал, старенький дир-300 умирает, а нет, попробую сегодня вечером помучаю свою 3200 с1

[s.lobanov]

Aksel

А вы на 100% уверены, что сверху приходит трафик, покрашенный на L3? Проверяли wireshark-ом непосредственно с проблемного свитча?

 

Если покрашен, то ок, предположим, что dscp trust и ACL-to-priority в самом деле бажные. Попробуйте тогда покрасить на L2(выше), чтоб 802.p у iptv-фреймов было не 0, например 5. Обычно на L2-свитчах проблем с приоритезацией по 802.1p-меткам нет. Надеюсь, что iptv у вас не untagged

[Aksel]

Aksel

А вы на 100% уверены, что сверху приходит трафик, покрашенный на L3? Проверяли wireshark-ом непосредственно с проблемного свитча?

 

Если покрашен, то ок, предположим, что dscp trust и ACL-to-priority в самом деле бажные. Попробуйте тогда покрасить на L2(выше), чтоб 802.p у iptv-фреймов было не 0, например 5. Обычно на L2-свитчах проблем с приоритезацией по 802.1p-меткам нет. Надеюсь, что iptv у вас не untagged

 

На видео, специально показал кусок из Wireshark что он идет покрашенный.

[Aksel]

А подробнее про метки L2 можете рассказать? Что то не до конца понял как реализовывать это.

[Aksel]

На ASR9k, создал полиси, применил ее на интерфейс смотрящий в мою сторону. Но в wireshark метку не вижу.

 

policy-map COS
class class-default
 set cos 7
!
end-policy-map
!

 

 

interface GigabitEthernet0/2/0/17.31 l2transport
encapsulation dot1q 31
rewrite ingress tag pop 1 symmetric
service-policy output COS

 

 

create igmp_snooping multicast_vlan TV 31
config igmp_snooping multicast_vlan TV state enable
config igmp_snooping multicast_vlan TV add member_port 1-24,27
config igmp_snooping multicast_vlan TV add source_port 25-26,28
config igmp_snooping multicast_vlan_group TV add  239.195.0.1-239.195.40.254,225.3.1.1-225.3.1.255,225.4.1.1-225.4.1.255

 

 

Кто то может резать метку? Des 3200-28?

[s.lobanov]

Вы метку ищите в тегированном трафике?

[Aksel]

Ну поставил драйвера на сетевую с поддержкой VLAN.

Добавил сетевую с TAG 31.

 

Перенастроил порт на tag_member_port и смотрю трафик. Верно же?

 

з.ы. чтобы реализовать cos нужно и клиентам отдавать тегированый мультикаст?

[zhenya`]

Кос поле в dot1q части фрейма.

 

По теме на крутить очереди и шедулинг механизм

Изменено 13 декабря, 2015 пользователем zhenya`

[Aksel]

Кос поле в dot1q части фрейма.

 

По теме на крутить очереди и шедулинг механизм

 

config scheduling_mechanism weight_fair
config scheduling 0 weight 1
config scheduling 1 weight 2
config scheduling 2 weight 4
config scheduling 3 weight 8
config 802.1p user_priority 0 0
config 802.1p user_priority 1 1
config 802.1p user_priority 2 2
config 802.1p user_priority 3 3
config 802.1p user_priority 4 2
config 802.1p user_priority 5 3
config 802.1p user_priority 6 2
config 802.1p user_priority 7 2
config cos tos value 0 class 0
config cos tos value 1 class 0
config cos tos value 2 class 0
config cos tos value 3 class 0
config cos tos value 4 class 0
config cos tos value 5 class 3
config cos tos value 6 class 3
config cos tos value 7 class 3

 

Вроде бы все что нужно сделал.

[zhenya`]

Вообще я тоже в своё время пробовал крутить и разницы особо не было ( вот на циске все сразу видно.. Достаточно wrr-queue bandwidth крутануть.. И сразу видно результат.. А тут хрен

[DRiVen]

Добавил сетевую с TAG 31.

Этого делать не нужно, драйвер снимает заголовок vlan, соответственно и cos тоже.

з.ы. чтобы реализовать cos нужно и клиентам отдавать тегированый мультикаст?

Да.

[Aksel]

Проще долбать D-link тогда чем переделывать всю сеть, по магистрали мультикаст ходит с тэгом, дальше садится на member port,а не на tag_member_port. Так что получается затея с cos провальная.

[mcdemon]

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

Главное от источника до коммутатора доступа догнать его тэгом с cos метками.

Главное ведь что-бы он до коммутатора конечного дошел крашенным. Но если вы подозреваете, что если порт 100% нагружен торрентами и конечный коммутатор шлет весь антег не приоритетно, то на конечных можно еще дополнительно навешать ACL правила для спокойства души...

[s.lobanov]

з.ы. чтобы реализовать cos нужно и клиентам отдавать тегированый мультикаст?

Да.

 

вы заблуждаетесь. 8021.p достаточно только на аплинк-портах

[DRiVen]

Да, вы правы, на направлении к клиенту не критично.