Введение
Традиционно, принимая во внимание, что cisco-адептов больше чем juniper-кунов, будут наблюдаться регулярные отсылки на названия и конкретные реализации той или иной технологии на Cisco IOS.
Вы можете ужаснуться от того как сложно это реализуется на Juniper, но, во-первых эта многословность дарит возможность очень гибкой и тонкой настройки, а во-вторых, монструозность CLI это лишь дело привычки и спустя недели лаб иерархичность Junos становится родной и понятной.
Легенда
Для обеспечения читателю возможности упорядоченного следования нам необходимо определиться с задачей, которую будет решать наша конфигурация.
Будет использоваться следующая схема, на базе реального оборудования:
- S3 – Juniper EX4200 – источник немаркированного трафика
- R1 – Juniper MX5 – точка выполнения CoS-манипуляций
- R3 – Cisco 3845 – получатель трафика
Как видите, для некоторого упрощения процесса, один из узлов работает на базе Cisco IOS – к этому узлу трафик будет направляться и там будет выполнятся классификация трафика, с целью определения корректности выполнения маркировки на R1.
Далее будут вноситься разъяснения в задачу, но поэтапно, чтобы не вызвать чувства запутанности.
Весь трафик будет направляться к трём loopback-интерфейсам на R3, со следующими IP-адресами:
- lo0 – 3.3.3.3
- lo1 – 123.0.0.1
- lo2 – 123.0.0.2
Эти адреса нужны чтобы можно было разделить трафик на три группы:
- трафик с адресом назначения 123.0.0.1 – считается высокоприоритетным трафиком телефонии (будем называть его телефонным);
- трафик с адресом назначения 123.0.0.2 – считается приоритетным трафиком важных корпоративных приложений (будем называть его серверным);
- трафик с адресом назначения 3.3.3.3 – считается обычным трафиком.
(легко запомнить, если смотреть на последний октет как на степень важности – 1=первая, максимальная важность).
Итак, мы имеет условный трафик, направляемый посредством утилиты ping, с S3 в сторону R3, через транзитный R1, который выполняет следующие манипуляции на интерфейсе ge-1/1/0:
- телефонный трафик маркируется DSCP EF, помещается в очередь VOICE и учитывается (кол-во байт и пакетов);
- серверный трафик маркируется DSCP AF31, помещается в очередь DATA и учитывается;
- обычный трафик маркируется DSCP BE, помещается в очередь OTHER и учитывается.
Очень важно поместить трафик в нужные и разные очереди, так как основные манипуляции выполняются именно с очередями – некими трубами, где трафик скапливается в ожидании своей участи.
Далее, как бы внутри устройства выполняются следующие манипуляции:
- очередь VOICE наделяется высшим приоритетом на передачу (LLQ), получает гарантированную полосу в 10% от общей полосы, без права выхода за рамки и 5% от общего объёма буферов без права выхода за рамки. Традиционно считается, что нет смысла давать много буферного пространства под трафик реального времени (голос, видео), ведь в случае перегрузки линии долгое время нахождения этого трафика в буфере будет бесполезной тратой ресурсов – к конечному узлу задержанный трафик придёт с большим опозданием, вероятно будучи уже не нужным, а значит его проще отбросить в момент когда мы предполагаем его уже опоздавшим;
- очередь DATA наделяется средним приоритетом, получает гарантированную полосу в минимум 40% от общей полосы, т.е. с правом выхода за рамки и гарантированные 50% от общего объёма буферов с правом выхода за рамки;
- очередь OTHER наделяется наименьшим приоритетом, получает всю незанятую кем-либо полосу и все незанятые кем-либо объёмы буферов от общего объёма буферов (доедает крошки со стола). При этом, за счёт именно этой очереди выполняется попытка избежания перегрузки (congestion avoidance – CA), с помощью WRED (weighted random early detection) – при достижении 70% занятости полосы отбрасываются 25% случайного трафика, при достижении 90%отбрасывается 50%. Это гораздо эффективнее чем базовый CA средствами Taildrop, благодаря которому при 100%перегрузке линии отбрасывается 100% трафика и рождается TCP global synchronization – график трафика будет выглядеть как зубчики пилы, ибо все TCP-сессии не получив ACK снижают свой MSS в 2 раза, показывая провал в графике и все вместе начинают передавать вновь, до повторения зубчика.
Настройка
Получатель
Давайте для начала выполним быструю настройку R3 – обеспечим классификацию трафика и убедимся, что весь трафик приходит немарированный:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
!
class–map VOICE
match ip dscp EF
class–map DATA
match ip dscp AF31
!
policy–map PM_CHECK
class VOICE
class DATA
class class–default
!
interface GigabitEthernet 0/0
service–policy input PM_CHECK
!
|
Мы выполняем простую Behavior aggregate (BA) классификацию пакетов, на основании DSCP, не применяя никаких действий к этому трафику. В итоге мы можем смотреть сколько пакетов одного из трёх классов с помощью одной простой командой:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
R3# show policy-map interface GigabitEthernet 0/0
GigabitEthernet0/0
Service–policy input: PM_CHECK
Class–map: VOICE (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: ip dscp ef (46)
Class–map: DATA (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: ip dscp af31 (26)
Class–map: class–default (match–any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
R3#
|
(для обычного трафика не создаём отдельный класс, а используем встроенный class-default)
Отправитель
Отправим несколько пакетов с S3 и убедимся, что весь данный трафик попадает в class-default, т.е., как минимум, ни метки EF, ни AF31 там нет (вывод сокращён, для улучшения читабельности):
|
1
2
3
4
5
6
7
8
9
10
|
root@S3# run ping 123.0.0.1 count 1 rapid
PING 123.0.0.1 (123.0.0.1): 56 data bytes
!
root@S3# run ping 123.0.0.2 count 2 rapid
PING 123.0.0.2 (123.0.0.2): 56 data bytes
!!
root@S3# run ping 3.3.3.3 count 3 rapid
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!
root@S3#
|
Проверим на R3:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
R3# show policy-map interface GigabitEthernet 0/0
GigabitEthernet0/0
Service–policy input: PM_CHECK
Class–map: VOICE (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: ip dscp ef (46)
Class–map: DATA (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: ip dscp af31 (26)
Class–map: class–default (match–any)
6 packets, 588 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
R3#
|
Как видите все 6 пришедших пакета успешно дошли до Получателя и попали в класс для немаркированного трафика.
Транзит
Это важно. Всю настройку мы разобьём на следующие этапы:
- Создание очередей
- Классификация, маркировка, помещение в очередь
- Создание планировщиков
- Привязывание очередей к планировщикам
- Закрепление на интерфейсе
- Policer
Создание очередей
Как уже говорилось ранее, очереди это те самые трубы в которые попадает трафик и в котором он ожидает своей участи. С точки зрения конфигурации нам это удобно для логического разделения трафика на блоки с которыми и творится вся магия. Т.е. раз у нас три типа трафика, то мы сделаем под них три разных очереди.
Отступление 1: конфигурацию Juniper можно приводить в нескольких вариантах – в длинном выводе формата конфигурационного файла, с кучей скобочек {{{{ }}}} а ля perl, либо в формате set, то как выполняется сама настройка. Мы будем использовать второй вариант с переходом по иерархическим уровням.
Отступление 2: все параметры указываемые исключительно буквами верхнего регистра являются именуемыми параметрами, имя для который выбирается администратором и задаётся вручную. В некоторых случая добавлено обозначение места куда применяется имя, чтобы не путаться, например RULE-VOICE, COUNTER-VOICE, SCHEDULER-VOICE.Всё это используется для улучшения читабельности конфигурации.
|
1
2
3
4
5
6
7
8
9
10
|
# Переходим на уровень настройки очередей
edit class–of–service forwarding–classes
# Создаём очередь VOICE и назначаем ей номер очереди 6.
# (доступны 8 очередей на порт, от 0 до 7)
set class VOICE queue–num 6
# очередь DATA
set class DATA queue–num 4
# очередь OTHER
set class OTHER queue–num 0
top
|
Надеюсь, такие конфигурации вас не пугают – перешли на уровень, сделали класс привязали его к какому захотели номеру очереди.
Проверим, что всё правильно создалось (несмотря на то, что безошибочный commit гарантирует это):
|
1
2
3
4
5
6
7
8
|
root@R1# run show class-of-service
Forwarding class ID Queue
OTHER 0 0
expedited–forwarding 1 1
assured–forwarding 2 2
network–control 3 3
VOICE 4 6
DATA 5 4
|
Видим все наши очереди и в столбце Queue видим номера.
Классификация, маркировка, помещение в очередь
Мы заведомо знаем, что трафик с S3 отправляется немаркированным, значит для того чтобы его классифицировать нам необходимо воспользоваться классификацией на основе Multi-field (MF) [т.е. отлов по любым значениям кроме самих меток CoS – по IP-адресам, портам, etc] – с самого начала мы определились, что специально для этого у нас есть три адреса назначения.
Процедура классификации, маркировки, подсчёта пакетов выполняется через обычный firewall-фильтр, который вещается на нужный интерфейс. В нашем случае это интерфейс ge-1/1/0 на R1 смотрящий в сторону S3.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
# Переходим на уровень настройки фильтра с именем MARK1
edit firewall family inet filter MARK1
# согласно правилу VOICE, любой пакет направляемый к 123.0.0.1,
# маркируется DSCP EF, кладётся в очередь VOICE,
# а количество/размер таких пакетов подсчитываются
set term TERM–VOICE from destination–address 123.0.0.1
set term TERM–VOICE then dscp ef forwarding–class VOICE count COUNTER–VOICE
# трафик с DSTIP 123.0.0.2, помечается DSCP AF31
# кладётся в очередь DATA и подсчитывается
set term TERM–DATA from destination–address 123.0.0.2
set term TERM–DATA then dscp af31 forwarding–class DATA count COUNTER–DATA
# прочий трафик явно перемаркируется DSCP BE
# (мало ли ктододумается весь свой трафик как EF маркировать),
# кладётся в очередь OTHER и подсчитывается
set term TERM–OTHER then dscp be forwarding–class OTHER count COUNTER–OTHER
top
|
Как видите конфигурация легко читается. Специально используется возможность Junos CLI, указания нескольких настроек сразу в одной строке. В конфигурации это выглядит иерархически и отдельно:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
firewall {
family inet {
filter MARK1 {
term TERM–VOICE {
from {
destination–address {
123.0.0.1/32;
}
}
then {
count COUNTER–VOICE;
forwarding–class VOICE;
dscp ef;
}
}
}
}
|
(представлен не полный вывод вышесозданного правила, а только ознакомительный блок TERM-VOICE).
Итак, мы сделали очереди, запихали туда трафик на основании известных о нём данных – самое время прикрепить фильтр на ближайших к S3 интерфейс – ge-1/1/0.
|
1
2
|
root@R1# set interfaces ge-1/1/0.0 family inet filter input MARK1
root@R1#
|
Прекрасно, проверяем – ещё раз отправляем пакеты до R3 и смотрим всё ли маркируется как было приказано.
Проверим для VOICE (помните, что это трафик до 123.0.0.1 ?):
|
1
2
3
4
5
6
7
8
9
|
! До отправки всё по нулям
R3# show policy-map interface GigabitEthernet 0/0 input class VOICE
GigabitEthernet0/0
Service–policy input: PM_CHECK
Class–map: VOICE (match–all)
0 packets, 0 bytes
30 second offered rate 0 bps
Match: dscp ef (46)
R3#
|
|
1
2
3
4
5
|
# Отправка
root@S3# run ping 123.0.0.1 count 6 rapid
PING 123.0.0.1 (123.0.0.1): 56 data bytes
!!!!!!
root@S3#
|
|
1
2
3
4
5
6
7
8
9
|
! Контрольная проверка
R3# show policy-map interface GigabitEthernet 0/0 input class VOICE
GigabitEthernet0/0
Service–policy input: PM_CHECK
Class–map: VOICE (match–all)
6 packets, 588 bytes
30 second offered rate 0 bps
Match: dscp ef (46)
R3#
|
Вуаля – пакеты вот прям реально маркируются на R1 и приходят таковыми до R3, где он может их классифицировать на основании BA – простого DSCP кода.
Мы так же можем зафиксировать корректную классификацию трафика на R1, просмотрев заблаговременно прикрученные счётчики:
|
1
2
3
4
5
6
7
8
|
root@R1# run show firewall filter MARK1
Filter: MARK1
Counters:
Name Bytes Packets
COUNTER–DATA 0 0
COUNTER–OTHER 0 0
COUNTER–VOICE 504 6
root@R1#
|
Создание планировщиков
Планировщики это те ребята которые будут управлять очередями на основании заданных нами правил. Именно здесь на очередях применяются все технологии QoS, от избежания перегрузок до управления доступным буферным пространством.
Раз у нас три типа трафика, три DSCP кода, три счётчика, три очереди, то и планировщиков (schedulers) будет три, со следующими именами:
- планировщик SCHED-VOICE для очереди VOICE;
- планировщик SCHED-DATA для очереди DATA;
- планировщик SCHED-OTHER для очереди OTHER.
Настоятельно рекомендую подняться в раздел “Легенда” и перечитать как именно планируется управлять очередями.
Итак:
Переходим на уровень настройки планировщиков
|
1
|
edit class–of–service schedulers
|
Планировщик SCHED-VOICE в будущем будет ассоциирован с очередью VOICE и выполняет следующие инструкции: выставляет наивысший приоритет трафику данной очереди (LLQ), обеспечивая максимально быструю отправку пакетов данной очереди, для обеспечения минимальной задержки и джиттера.
|
1
|
set SCHED–VOICE priority strict–high
|
Так как лучше отбросить трафик реального времени, вместо долгосрочной задержки в буферах, мы выдаём данной очереди только 5% объёма буферов, без права эти пределы превысить, таким образом, когда буфер заполнен, мы не может поместить в него новые пакеты и отбрасываем их, надеясь, что перегрузка вот-вот прекратится.
|
1
|
set SCHED–VOICE buffer–size percent 5 exact
|
Далее нам нужно ограничить максимально утилизируемую голосовым трафиком полосу пропускания, так как если этого не сделать, то наделяя его наивысшим приоритетом, мы рискуем, что при правильных объёмах голоса никакой другой трафик не пролезет вовсе. Сделать это можно несколькими путями:
- shaping-rate – суть метода заключается в буферизации трафика перед отправкой, что для голоса не годится;
- transmit-rate – гарантирует часть полосы, при этом, если трафика больше, то совершаются попытки использовать никем не занятую пропускную способность, что для нашего случая не походит, так как нам необходимо жёстко лимитировать полосу под голос, ибо приоритет опасен;
- transmit-rate exact – гарантируется часть полосы и всё что выходит за рамки попросту отбрасывается. К сожалению, наивысший приоритет и transmit-rate exact не могут использоваться одновременно и при попытке сделать это Junos ругнётся следующим образом: “cos_config_scheduler_attributes: cannot configure transmit rate exact and priority strict-high at the same time.”
- policer – последний и идеальный вариант для ограничения полосы под голос, так как во-первых policing, в отличие от shaping, не использует такой ограниченный ресурс как буферы для временного хранения чего-либо, а во-вторых имеются интересные возможности – вместо отбрасывания голосового трафика при превышении лимитов, можно перемаркировывать его (например в DSCP BE) или просто отдать в очередь BE, надеясь что там дальше разберуться сами. Т.е. мы обещаем что до считаем голос особенным только до определённого предела. Настройки конкретного устройства ответственны за то чтобы избегать или управлять перегрузками только на нём самом, поэтому подход с понижением приоритета вместо отброса имеет право существовать. Таким образом, мы обходим проблему буферов, отброса важного трафика и опасности переполнения линии высокоприоритетным трафиком.
Делается это не в планировщиках и мы вернёмся к этому чуть позже.
Конец планировщика SCHED-VOICE
Для очереди которая будет привязана к планировщику SCHED-DATA (у нас это будет DATA), выполняются следующие условия: средний приоритет, позволяющий обеспечить отправку пакетов из очереди данного планировщика, раньше чем ожидающие пакеты из очередей с меньшим приоритетом.
|
1
|
set SCHED–DATA priority medium–high
|
Такого трафика ожидается много, но мы гарантируем ему только 40% буферного пространства
|
1
|
set SCHED–DATA buffer–size percent 40
|
, а так же гарантируем 50% пропускной способности, при этом не жёстко ограничиваем его в этих рамках, т.е. если часть линии свободна, он может её занять
|
1
|
set SCHED–DATA transmit–rate percent 50
|
Для обычного трафика, как и договорились, остаются все объедки не съеденные явным # образом кем-то более привилегированным
|
1
2
|
set SCHED–OTHER buffer–size remainder
set SCHED–OTHER transmit–rate remainder
|
Без комментариев список команд конфигурации выглядит так:
|
1
2
3
4
5
6
7
8
9
|
edit class–of–service schedulers
set SCHED–VOICE priority strict–high
set SCHED–VOICE buffer–size percent 5 exact
set SCHED–DATA priority medium–high
set SCHED–DATA buffer–size percent 40
set SCHED–DATA transmit–rate percent 50
set SCHED–OTHER buffer–size remainder
set SCHED–OTHER transmit–rate remainder
top
|
Согласитесь – ничего пугающего.
Привязка очередей к планировщикам
Согласно уговору привязываем планировщики к одноимённым классам (воису воисово, дате датово, кесарю кесарево). Нашу карту планировщиков назовёт SCHEDMAP1:
|
1
2
3
4
5
|
edit class–of–service scheduler–maps SCHEDMAP1
set forwarding–class VOICE scheduler SCHED_VOICE
set forwarding–class DATA scheduler SCHED_DATA
set forwarding–class OTHER scheduler SCHED_OTHER
top
|
Закрепление на интерфейсе
Всё основное мы сделали, осталось зацепить это на тот интерфейс смотрящий в сторону R3 – ge/1/1/1 и после этого там же обеспечить там policing.
Привязка к интерфейсу:
|
1
|
set class–of–service interfaces ge–1/1/1 unit * scheduler–map SCHEDMAP1
|
Policer
Уже сейчас всё нами настроеное находится в эксплуатации и нарезается раздаётся согласно тем условиями которые мы указали.
Осталось “зарезать” голосовой трафик, чтобы защитить себя от обработки только высокоприоритетных пакетов. Есть два уточнения благодаря которым мы поймём как и где это делать:
- policing можно использовать как для входящего трафика, так и для исходящего, в отличие от shaping, который не особо разумен для входящего трафика, так как буферы уже были использованы для трафика который отбросится;
- как и многие другие вещи, policing выполняется посредством firewall filter, который назначается на некоторый интерфейс;
Собственно из этого можно сделать вывод, что ничего не мешает и даже следует использовать policing уже в составе имеющегося фильтра на порту ge-1/1/0, смотрящего в сторону S3!
Для начала создадим сам policer, чтобы можно было его поместить как условие в наш фильтр.
|
1
2
3
4
|
edit firewall policer POLICER1
set if–exceeding bandwidth–percent 10 burst–size–limit 1m
set then forwarding–class OTHER
top
|
Вы наверняка заметили, что правила фаервольных полисеров и фильтров очень удобно читать – если так, то делать вот это.
В нашем случае мы говорим, что если нечто, к чему будет применён данный полисер пытается занять больше положенных 10% от пропусной способности линии (10Мб/с для 100Мбит/с), то трафик сверх этого лимита стоит переместить в класс OTHER, для которого как вы помните имеется большой выбор крошек. Мы не станем перемаркировывать трафик, а просто поместим в очередь для обычного трафика, где он, если выживет, то может на следующей узле всё будет хорошо, и на основании его сохранившего DSCP EF, его обслужат его как подабает таким особам.
Далее, мы имеем следующий фильтр, на интерфейсе, смотрящем в сторону S3:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
root@R1# show firewall family inet
filter MARK1 {
term VOICE {
from {
destination–address {
123.0.0.1/32;
}
}
then {
count COUNTER–VOICE;
forwarding–class VOICE;
dscp ef;
}
}
term DATA {
from {
destination–address {
123.0.0.2/32;
}
}
then {
count COUNTER–DATA;
forwarding–class DATA;
dscp af31;
}
}
term OTHER {
then {
count COUNTER–OTHER;
forwarding–class OTHER;
dscp be;
}
}
}
root@R1#
|
Значит нам необходимо прицепить только что созданный policer POLICER1 к правилу TERM-VOICE:
|
1
|
set firewall family inet filter MARK1 term VOICE then policer POLICER1
|
В итоге правило TERM-VOICE обретёт следующий вид:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
root@R1# show firewall family inet filter MARK1 term VOICE
from {
destination–address {
123.0.0.1/32;
}
}
then {
policer POLICER1;
count VOICE;
forwarding–class VOICE;
dscp ef;
}
root@R1#
|
Только-только трафик будет классифицирован, маркирован и помещён в очередь, как тут же будет проверен и на соответствие правилу допустимой ему полосы пропускания.
Рассморение калькуляции значения burst-size преднамеренно не упоминается в рамках статьи, для обеспечения небольшого уровня сложности текста.
Проверка
Не сказать, что Junos достоин похвалы за удобство проверки корректности работы, но инструменты имеются.
show class-of-service
show class-of-service scheduler-map
show class-of-service scheduler-map SCHEDMAP1
show class-of-service drop-profile
show class-of-service drop-profile DROPMAP1
show class-of-service interface ge-1/1/1 comprehensive | find “Scheduler map”
show class-of-service interface
show class-of-service interface ge-1/1/1
show class-of-service interface ge-1/1/1 comprehensive | find “CoS info”
show interfaces ge-1/1/0 extensive detail | find “CoS info”
show interfaces queue ge-1/1/1
Дополнения
Микросекунды
Для голосового трафика может быть полезным указать размер буфера не в процентах, а явным образом, в микросекундах, ограничив тем самым время жизни трафика который уставает задержаваясь в буферах. Известно, что delay голосового трафика, при котором наблюдается явная деградация звука имеется уже на 150мс. Так как данный параметр выставляется в микросекундах, что на три порядка меньше миллисекунды, 150мс будут выглядеть как 150000, но мы поставишь чуть меньше:
|
1
2
|
delete class–of–service schedulers SCHED_VOICE buffer–size
set class–of–service schedulers SCHED_VOICE buffer–size temporal 100000
|
RED
Совсем забыли про необходимость пытаться избегать перегрузки на линии, за счёт предварительного отбрасывания части пакетов полуслучайным образом – random early detection (RED).
Разумеется, это будет делаться за счёт трафика в очереди класса OTHER, который у нас best-effort.
Согласно легенде будет выполняться следующее: “при достижении 70% занятости полосы отбрасываются 25% случайного трафика, при достижении 90% отбрасывается 50%”.
Настраивается всё в отдельной ветке иерархии и после цепляется к нужному планировщику:
|
1
2
3
4
|
edit class–of–service drop–profiles DROPMAP1
set fill–level 70 drop 25
set fill–level 90 drop 50
top
|
Как видите и здесь блок конфигурации отлично читается.
Обновим на ходу планировщик SCHED_OTHER:
|
1
|
set class–of–service schedulers SCHED_OTHER drop–profile–map protocol any loss–priority any drop–profile DROPMAP1
|
Проверка:
|
1
2
3
4
5
|
root@R1> show class–of–service drop–profile DROPMAP1
Drop profile: DROPMAP1, Type: discrete, Index: 13794
Fill level Drop probability
70 25
90 50
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
root@R1> show class–of–service scheduler–map SCHEDMAP1
Scheduler map: SCHEDMAP1, Index: 20828
Scheduler: SCHED_OTHER, Forwarding class: OTHER, Index: 47444
Transmit rate: remainder, Rate Limit: none, Buffer size: remainder, Buffer Limit: none, Priority: low
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 13794 DROPMAP1
Medium low any 13794 DROPMAP1
Medium high any 13794 DROPMAP1
High any 13794 DROPMAP1
Scheduler: SCHED_VOICE, Forwarding class: VOICE, Index: 15390
Transmit rate: 5 percent, Rate Limit: none, Buffer size: 100000 us, Buffer Limit: none, Priority: strict–high
Excess Priority: unspecified
Shaping rate: 50000 bps, Shaping Rate Burst: 31000 bytes
Drop profiles:
Loss priority Protocol Index Name
Low any 1 <default–drop–profile>
Medium low any 1 <default–drop–profile>
Medium high any 1 <default–drop–profile>
High any 1 <default–drop–profile>
Scheduler: SCHED_DATA, Forwarding class: DATA, Index: 57929
Transmit rate: 30 percent, Rate Limit: none, Buffer size: 40 percent, Buffer Limit: none, Priority: low
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 1 <default–drop–profile>
Medium low any 1 <default–drop–profile>
Medium high any 1 <default–drop–profile>
High any 1 <default–drop–profile>
root@R1#
|
Источники
Configuring Large Delay Buffers in CoS
Configuring CoS Hierarchical Schedulers
Enabling Class of Service on EX Series Switches in a Campus LAN [pdf]
Example: Configuring CoS on EX Series Switches