Jump to content
Калькуляторы

Cisco 3750X. Рекомендации QoS для multicast

Коллеги, может кто-то поделиться рекомендациями по настройке QoS для Cisco 3750X для multicast трафика. В целом с работой QoS на данном коммутаторе разобрался, но не хватает опыта. Интересуют:

 

1. Каким DSCP обычно метят мультикаст: СS5 или EF?

 

2. Для Ingress: примерные параметры очередей (buffers), параметры SRR шедулера (bandwidth) и параметры для WTD

 

3. Для Egress: примерные параметры очередей (buffers), параметры SRR шедулера (bandwidth) и параметры для WTD. Нужно ли явно включать приоритетную очередь?

 

Входящего мультикаста примерно 1.4 Гб/с, исходящего 1.2 Гб/с.

Edited by fox_m

Share this post


Link to post
Share on other sites

1. Метят в зависимости от настроек все сети, в целом, можете хоть 0 ставить, главное чтобы на всех устройствах оно трактовалось одинаково. На каталистах EF обычно помечен голосовой трафик, лучше используйте CS4.

2, 3. Оставьте buffers/WTD по умолчанию и наблюдайте за статистикой потерь на очередях, если будут то увеличивайте буферы (если конечно трафик дропается из-за нехватки буферов а не из-за переподписки или полисера/шедулера). SRR настройте в режиме shared round robin (на обычных 3750 на ingress SRR умеет только shared, на egress умеет shared и shaped, по умолчанию включен shaped что вам не подходит). Приоритетную очередь очень желательно включить, без нее даже на небольших мультикаст-потоках бывают дропы.

Share this post


Link to post
Share on other sites

2,3. Поправка, при включении приоритетной исходящей очереди она не шейпится, поэтому настройки shared или shaped на ваш мультикаст трафик летящий в эту очередь не повлияют.

Share this post


Link to post
Share on other sites

2,3. Поправка, при включении приоритетной исходящей очереди она не шейпится, поэтому настройки shared или shaped на ваш мультикаст трафик летящий в эту очередь не повлияют.

 

Вот кстати вопрос по приоритетной очереди. Допустим у меня такие настройки на интерфейсе:

 

srr-queue bandwidth shape 50 0 0 0
srr-queue bandwidth share 20 20 20 20
priority-queue out

 

Получается очередь №1 становится приоритетной. Ведь только первая очередь может стать приоритетной? Настройки share (50) и shape (20) перестают для нее действовать. А сколько она вообще станет потреблять ресурсов? Или тупо пока она не очистится другие очереди не обслуживаются?

Edited by fox_m

Share this post


Link to post
Share on other sites

1. Метят в зависимости от настроек все сети, в целом, можете хоть 0 ставить, главное чтобы на всех устройствах оно трактовалось одинаково. На каталистах EF обычно помечен голосовой трафик, лучше используйте CS4.

2, 3. Оставьте buffers/WTD по умолчанию и наблюдайте за статистикой потерь на очередях, если будут то увеличивайте буферы (если конечно трафик дропается из-за нехватки буферов а не из-за переподписки или полисера/шедулера). SRR настройте в режиме shared round robin (на обычных 3750 на ingress SRR умеет только shared, на egress умеет shared и shaped, по умолчанию включен shaped что вам не подходит). Приоритетную очередь очень желательно включить, без нее даже на небольших мультикаст-потоках бывают дропы.

 

По умолчанию настройка такая:

 

GigabitEthernet1/0/1

QoS is disabled. When QoS is enabled, following settings will be applied

Egress Priority Queue : disabled

Shaped queue weights (absolute) : 25 0 0 0

Shared queue weights : 25 25 25 25

The port bandwidth limit : 100 (Operational Bandwidth:100.0)

The port is mapped to qset : 1

 

Получается, очередь только очередь №1 работает в shaped режиме и под нее выделено всего 1/25 пропускной способности интерфейса. Так? Получается, нужно сделать как то так?

 

srr-queue bandwidth shape 0 0 0 0
srr-queue bandwidth share 25 25 25 25
priority-queue out

Share this post


Link to post
Share on other sites

Ведь только первая очередь может стать приоритетной?

Да.

А сколько она вообще станет потреблять ресурсов? Или тупо пока она не очистится другие очереди не обслуживаются?

Пока не закончатся кадры. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_53_se/configuration/guide/3750xscg/swqos.html#wp1163879 :

 

You can ensure that certain packets have priority over all others by queuing them in the egress expedite queue. SRR services this queue until it is empty before servicing the other queues.

 

Получается, очередь только очередь №1 работает в shaped режиме и под нее выделено всего 1/25 пропускной способности интерфейса. Так?

Да, и насколько помню в нее по умолчанию кладутся кадры с COS5 или DSCP EF (в зависимости от trust на входящих портах).

Получается, нужно сделать как то так?

Не уверен, если не ошибаюсь как только очередь назначается приоритетной настройки shape/share для нее перестают действовать.

Share this post


Link to post
Share on other sites

Ага, понял. Еще подскажите, что бы защитить telnet/ssh подключение к коммутатору, когда много трафика через коммутатор идет, нужно QoS настраивать или это область Control Plane portection?

Share this post


Link to post
Share on other sites

CoPP специально предназначен для защиты от лишнего трафика, использовать вместо него фильтры на интерфейсах без веских причин мягко говоря неразумно.

К сожалению на обычных 3750 CoPP нету, на 3750X вроде тоже отсутствует.

 

что бы защитить telnet/ssh подключение к коммутатору, когда много трафика через коммутатор идет

Не понял что имеете ввиду, транзитный трафик на CPU не попадает. QoS не при чем хотя на 3750 трафик можно зарезать и им (установив маленькую скорость или дропая пакеты в policy-map).

Для защиты от подключений с несанкционированных адресов используйте ACL на VTY, только это софтверная фича - прилетевшие запросы обрабатываются CPU, если требуется строгая политика безопасности ограничивайте доступ с помощью ACL на портах или SVI.

Share this post


Link to post
Share on other sites

CoPP специально предназначен для защиты от лишнего трафика, использовать вместо него фильтры на интерфейсах без веских причин мягко говоря неразумно.

К сожалению на обычных 3750 CoPP нету, на 3750X вроде тоже отсутствует.

 

что бы защитить telnet/ssh подключение к коммутатору, когда много трафика через коммутатор идет

Не понял что имеете ввиду, транзитный трафик на CPU не попадает. QoS не при чем хотя на 3750 трафик можно зарезать и им (установив маленькую скорость или дропая пакеты в policy-map).

Для защиты от подключений с несанкционированных адресов используйте ACL на VTY, только это софтверная фича - прилетевшие запросы обрабатываются CPU, если требуется строгая политика безопасности ограничивайте доступ с помощью ACL на портах или SVI.

 

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

Share this post


Link to post
Share on other sites

на свичах насколько крутого коса нет, чтобы получить такой кейс)

Share this post


Link to post
Share on other sites

По опыту на 3750 с мультиком все плохо (из-за буферов, видимо) при сколько-нибудь значимость трафике, как ни куось

 

В лохматые годы тупо заменив кучку 3750 на 6500 получили разительное повышение качества

Share this post


Link to post
Share on other sites

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

Для трафика к коммутатору надо настраивать QoS на транзитных каналах, ведь "полочка" на канале возникает до свитча и все что ему остается лишь принять трафик. Можно ingress queue на самом 3750 настроить однако не думаю что разницу заметите. В вашем случае возможно проще всего будет маркировать трафик telnet так же как мультикаст.

Для трафика от коммутатора (если и на них "полочка") надо настраивать QoS и на самом коммутаторе и на транзитных линках, в частности матчить по tcp port 23 и отправлять в отдельную очередь. На 3750 такое не настраивал, примеры конфига не приведу.

На C3750 это сработает потому что входящий на CPU трафик проходит через ingress queue а исходящий от CPU трафик через egress queue (на многих платформах есть специальные очереди для трафика от/к CPU и настройки QoS на них не влияют).

Share this post


Link to post
Share on other sites

Вообще платформы 2960,3560,3750 весьма посредственны в работе с буффером, если Вам нужно гарантировать доставку какого-то трафика, тем более мультикаста, особенно если его много, то придется мирится с дропами в низкоприоритетных очередях.

Вот рабочий конфиг qos (без маркировки, она в другом месте у нас делается) с 3560x, мультикаста (iptv) на нем много, он маркирован в af41, так же есть voip в ef. Дропов мультикаста и воипа нет, дропы остального трафика от 0 до 0.1%

cat-kor#show running-config | inc mls qos
mls qos srr-queue output cos-map queue 1 threshold 1 3 4
mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 2 0 1 2
mls qos srr-queue output cos-map queue 4 threshold 3 6 7
mls qos srr-queue output dscp-map queue 1 threshold 1 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 1 threshold 1 32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output dscp-map queue 2 threshold 2 0 1 2 3 4 5 6 7
mls qos srr-queue output dscp-map queue 2 threshold 2 8 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 2 threshold 2 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 4 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 4 threshold 3 56 57 58 59 60 61 62 63
mls qos queue-set output 1 threshold 1 1800 10 40 3200
mls qos queue-set output 1 threshold 2 20 2400 40 3200
mls qos queue-set output 1 threshold 3 1 1 1 1
mls qos queue-set output 1 threshold 4 10 10 90 1200
mls qos queue-set output 2 threshold 1 10 10 50 1600
mls qos queue-set output 2 threshold 2 10 3200 100 3200
mls qos queue-set output 2 threshold 3 1 1 1 1
mls qos queue-set output 2 threshold 4 10 10 90 400
mls qos queue-set output 1 buffers 45 45 0 10
mls qos queue-set output 2 buffers 10 80 0 10
no mls qos rewrite ip dscp
mls qos

 

Интерфейс в сторону потребителей мультикаста:

interface GigabitEthernet0/1
...
srr-queue bandwidth share 45 40 8 7
priority-queue out
no ip igmp snooping tcn flood
ip igmp filter 1

Интерфейс в сторону абонентов не потребляющих мультикаст

interface GigabitEthernet0/2
....
srr-queue bandwidth share 20 65 8 7
queue-set 2
no ip igmp snooping tcn flood

 

Дропы, только 1 пакет дропунся в интернет очереди.

cat-kor#show mls qos interface gi0/1 statistics
GigabitEthernet0/1 (All statistics are in packets)
.....
 output queues enqueued:
queue:    threshold1   threshold2   threshold3
-----------------------------------------------
queue 0:  2260948042           0           0
queue 1:           0   345546305   118580551
queue 2:           0           0           0
queue 3:           0           0   118391222

 output queues dropped:
queue:    threshold1   threshold2   threshold3
-----------------------------------------------
queue 0:           0           0           0
queue 1:           0           1           0
queue 2:           0           0           0
queue 3:           0           0           0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this