Глава 4. Scheduling: различия между версиями

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
(Новая страница: «== Port-based queues == Каждый порт может содержать 4-8 очереди. '''PQ-DWRR''': priority queue deficit round-robin: механи…»)
 
м
 
(не показано 38 промежуточных версий этого же участника)
Строка 1: Строка 1:
== Port-based queues ==
{{#description2:Основы scheduling. Шедулер. Port-based очереди. Компоненты scheduling: Transmission rate, Queue priority, Drop profiles (RED/WRED). Scheduler map. Конфигурация Scheduler. Информация для подготовки к экзаменам Juniper.}}
=Основы scheduling=
С помощью классификатора определили трафик в разные очереди, теперь нужно как-то трафик обрабатывать. Этим процессом как раз занимается scheduler:
*Порядок передачи пакетов
*Скорость передачи пакетов
*Кол-во пакетов, которое можно забуфферизировать
*Разные способы обработки пакетов в случае заторов на сети.


Разная обработка трафика на основании loss-priority.
*Классификация или полисер назначили PLP
*PLP соответствует scheduling traffic profile
*Traffic profile соответствует drop profile
*Drop profile определяет вероятность отброса трафика
=Port-based очереди (queues)=
Каждый порт может содержать 4-8 очереди.
Каждый порт может содержать 4-8 очереди.
Одной очереди может быть назначено более одного forwarding class.


'''PQ-DWRR''': priority queue deficit round-robin: механизм для выбора очереди и последующей передачи пакета. Priority - очереди обслуживаются в порядке, сконфигурированном для очередей.
'''PQ-DWRR''': priority queue deficit round-robin: механизм для выбора очереди и последующей передачи пакета. Priority - очереди обслуживаются в порядке, сконфигурированном для очередей.
Строка 7: Строка 22:
'''WRED''': Weighted random early detection: механизм для отброса пакетов. Основан на сконфигурированных параметрах: fw-class, PLP. С помощью него можно избежать и контролировать заторы.
'''WRED''': Weighted random early detection: механизм для отброса пакетов. Основан на сконфигурированных параметрах: fw-class, PLP. С помощью него можно избежать и контролировать заторы.


== Scheduling components ==
= Компонениы Scheduling =
 
==Transmission rate ==
=== Transmission rate ===
'''Transmission rate''' - кол-во пропускной способности от физического интерфейса, выделенной для этой очереди. Похоже на CIR.
 
- '''Transmission rate''' - кол-во пропускной способности от интерфейса, выделенной этой очереди. Похоже на CIR.
 
Queue can exceed trans rate if there is unused bandwidth. Тут также используется терминология in-profile, out-of-profile, смысл такой же как и для CIR.
 
edit class-of-service schedule schedule-name transmit-rate (''rate | percent | remainder'') exact | rate-limit
 
'''remainder''' - заполнение оставшегося буфера.


'''exact''' - буферизирует трафик, который превысил transm rate.
Очередь может превышать tranmission rate, если есть неиспользуемая полоса (использовать большую полосу, чем выделили изначально). Тут также используется терминология in-profile, out-of-profile.


'''rate-limit''' - дропает трафик, который превысил transm rate.
edit class-of-service schedule ''<schedule-name>'' '''transmit-rate''' (''rate | percent | remainder'') exact | rate-limit


'''no settings''' - очередь может превысить transm rate, если есть неиспользуемая полоса.
*'''remainder''' - заполнение оставшегося буфера.
*'''exact''' - буферизирует трафик, который превысил transm rate. При наличие неиспользуемой свободной полосы не будет давать очереди её использовать.
*'''rate-limit''' - дропает трафик, который превысил transm rate.
*'''no settings''' - очередь может превысить transm rate, если есть неиспользуемая полоса.


Есть значения по умолчанию. Так как по умолчанию в джуне созданы 2 fw-class (best-effort (0) и network-control (3)), то дефолтные параметры есть только для этих очередей.
Есть значения по умолчанию. Так как по умолчанию в джуне созданы 2 fw-class (best-effort (0) и network-control (3)), то дефолтные параметры есть только для этих очередей.
Строка 39: Строка 49:
Чтобы исключить очередь, используем exact или rate-limit в настройке.
Чтобы исключить очередь, используем exact или rate-limit в настройке.


===Queue priority===
==Приоритет очереди==
 
'''Priority''' - приоритет среди других очередей. Во времена запоров приоритетом определяется в каком порядке будут обрабатываться очереди.
- '''Priority''' - приоритет среди других очередей. Во времена запоров приоритетом определяется в каком порядке будут обрабатываться очереди.


Значения:  
Значения:  
*Low
*Medium-low
*Medium-high
*High
*Strict-high - traffic always in-profile. Пакеты в этой очереди всегда в первую очередь используют необходимую полосу.


- Low
Остальные очереди передают трафик в порядке убывания приоритета от high к low.
 
- Medium-low
 
- Medium-high


- High
Трафик в in-profile (по transmission rate) low priority, будет обрабатывается до трафика out-profile strict priority.


- Strict-high - traffic always in-profile. Пакеты в этой очереди всегда в первую очередь используют необходимую полосу.
То есть сначала вне зависимости обрабатывается трафик в in-profile, только потом out-profile.


Остальные очереди используют WRR чтобы распределить полосу.
Но при этом, при передаче каждого пакета в очереди, ниже strict, происходит проверка - есть ли в очереди пакеты из более высокой очереди. Если есть, то начинают передаваться они, а потом продолжает передавать прежняя очередь (если за это время не набежало пакетов из тоже приоритетной очереди).


'''НО!''' очереди с высоким приоритетом, но имеющие пакеты в out-of-profile будут иметь меньший приоритет, чем очереди с низким приоритетом, но не имеющие пакеты в out-of-profile.
Strict-priority - опсана! она может сожрать всю полосу и остальные очереди могут "голодать". Но High-prioroty делит полосу с Strict.  


Strict-priority - опсана! она сжирает всю полосу и остальные очереди могут "голодать". Но High-prioroty делит полосу с Strict.  
Чтобы не происходило голодания, мы можем:
#также важным очередям назначать  high-priotity.
#для strict-priority задавать в transm-rate ''rate-limit''.


Чтобы не происходило голодания, мы можем: 1. также важным очередям назначать  High-priotity. 2. для strict-priority задавать в transm-rate ''rate-limit''.
Разрешается задавать 1 strict-priority на 1 интерфейс.


Разрешается задавать 1 Strict-priority на 1 интерфейс.
edit class-of-service schedule ''<schedule-name>'' '''priority''' ''< high / low / medium-high / medium-low / strict-high >''


edit class-of-service schedule schedule-name priority '' ... ''
Дефолтные значения для дефолтных fw-class: '''best-effort - ''low'' ''', '''network-control - ''low'' '''.


Дефолтные значения для дефолтных fw-class: best-effort - low, network-control - low.
== Delay buffers ==
 
=== Delay buffers ===


- '''Delay buffers''' - кол-во данных, кот можно хранить.
- '''Delay buffers''' - кол-во данных, кот можно хранить.
Строка 75: Строка 85:
larger buffer = many packet stores = large supported latency.
larger buffer = many packet stores = large supported latency.


Buffer size - это параметр, определяющийся пропускную способностью интерфейса и также зависит от платформы.
Buffer size - это параметр, определяющийся размер буфера интерфейса и также зависит от платформы.


  edit class-of-service schedule schedule-name buffer-size ''percent | temporal | remainder''
  edit class-of-service schedule ''<schedule-name>'' '''buffer-size''' ''<percent | temporal | remainder>''


'''percentage''': буфер "эластичный", когда очередь начинает использовать бОльшую полосу, чем ей было выделено изначально (transm-rate), буфер будет автоматически увеличиваться.
'''percentage''': буфер "эластичный", когда очередь начинает использовать бОльшую полосу, чем ей было выделено изначально (transm-rate), буфер будет автоматически увеличиваться.
Строка 91: Строка 101:
  для очереди 1 - задаем percentage = 45%: effective delay buffer = 45 ms, buffer size = 0,045 s * 1000 Mbps /8 = 5.625 MB
  для очереди 1 - задаем percentage = 45%: effective delay buffer = 45 ms, buffer size = 0,045 s * 1000 Mbps /8 = 5.625 MB


'''temporal''': для задания размера такого буфера используются мс. буфер не эластичный, имеет строгий верхний лимит и дропает весь трафик, превышающий этот лимит. Для вычисления оптимального размера буфера используется значение transmission-rate.
'''temporal''': для задания размера такого буфера используются мс. Буфер не эластичный, имеет строгий верхний лимит и дропает весь трафик, превышающий этот лимит. Для вычисления оптимального размера буфера используется значение transmission-rate.


  buffer size (MB) = max buffer size (s) * transmit rate (Mbps) / 8
  buffer size (MB) = max buffer size (s) * transmit rate (Mbps) / 8
Строка 107: Строка 117:
'''remainder''': использует все не занятое другими очередями пространство.
'''remainder''': использует все не занятое другими очередями пространство.
   
   
Когда мы выставляем buffer size и transm rate в процентном соотношении, хорошей практикой считается выставлять пропорциональные(равные) значения, но это не обязательно вообще.
Когда мы выставляем buffer size и transm rate в процентном соотношении, хорошей практикой считается выставлять пропорциональные (равные) значения, но это не обязательно вообще.
 
В обоих случаях размер буффера будет увеличиваться при увеличении transm rate.
В обоих случаях размер буффера будет увеличиваться при увеличении transm rate.


'''Default scheduler settings''': Для best-effort - 95, для netw-control - 5, что равно дефолтным значениям transm-rate.
'''Default scheduler settings''': Для '''best-effort - ''95'' ''', для '''netw-control - ''5'' ''', что равно дефолтным значениям transm-rate.


=== Drop profiles ===
== Drop profiles (RED/WRED)==
 
'''RED drop profiles (random early discard)''' - как отбрасывать трафик, когда возникает запор. Работает напрямую с буфферами. Отбрасывание пакетов зависит от заполненности буфера.
- '''RED drop profiles''' - как отрасывать трафик, когда возникает запор. Работает напрямую с буфферами, берет трафик, который не поместился в буффер.


Определяет параметры отброшенного трафика, назначает PLP для использования (set on a packet at ingress).
Определяет параметры отброшенного трафика, назначает PLP для использования (set on a packet at ingress).


'''Параметры''':
При этом в RED из-за "случайно отброшенных" пакетов может возникнуть такая ситуация, когда некоторые пакеты одного потока будут отброшены, тогда source перестанет получать acknowledgement от receiver. При этом затор на уже почти перегруженном линке будет только увеличиваться.


'''fullness''': наполненность буффера.
В связи с этим более эффективно использовать WRED, он полностью не уберет проблему с "нечестным" отбросом пакетов из одного потока, но хотя бы можно исключить подобную ситуацию для трафика, нетерпимого к подобным потерям. О нем дальше.
===Параметры WRED===
#'''fullness''': наполненность буффера.
#'''drop probability''': вероятность, что пакет будет отброшен.


'''drop probability''': вероятность, что пакет отбросится.
Для drop-profile задаём значения для этих двух параметров.
 
По сути получается линия на графике, где соотносятся fullness (%) к drop probability (%).
По сути это линия на графике, где соотносятся fullness (%) и drop probability (%).


'''How it works''':
'''How it works''':
#Для каждого пакета в очереди маршрутизатор назначает любое число от 0-100.
#Числа нанесены на график отношения fullness к drop probability (по оси fullness).
#Когда случайный номер выше линии, пакет передается.
#Когда случайный номер ниже линии, пакет дропается.


1. Для каждого пакета в очереди маршрутизатор назначает любое число от 0-100.
Чтобы сделать более тонкую обработку трафика, рекомендуется создать несколько drop pofiles с разной "агрессивностью", и применять каждый к разному типу трафика.


2. Числа нанесены на график отношения fullness и drop probability (по оси fullness).
Такой подход является более взшешанным (weighted RED = '''WRED''').


3. Когда случайный номер выше линии, пакет передается.
Если для очереди назначен менее агрессивный drop profile, то она полностью будет использовать буффер - такой drop-profile хорошо использовать для более приоритетного трафика. Если используем более агрессивный, то буффер не будет заполняться до конца - подобное поведение свойственно менее приоритетному трафику.


4. Когда случайный номер ниже линии, пакет дропается.
Когда мы настраиваем drop profile таким образом, что fullness < 100%, drop probability = 100%, мы таким образом уменьшаем эффективный максимальный размер буффера. То есть с помощью drop-profile мы можем влиять на "рабочий" размер буфера.
 
Рекомендуется создать несколько drop pofiles с разной "агрессивностью", и применять к разному типу трафика.
 
Такой подход является более взшешанным (weighted RED = WRED).
 
Когда мы настраиваем drop profile таким образом, что fullness < 100%, drop probability = 100%, мы таким образом уменьшаем effective maximum buffer size.
 
Если для очереди назначен менее агрессивный drop profile, то она полностью будет использовать буффер. Если используем более агрессивный, то буффер не будет заполняться до конца, что есть хорошо! 
 
'''Config options'''


===Config options===
Помимо drop probability и fullness при конфигурации следует учитывать, что эти параметры могут задаваться:
Помимо drop probability и fullness при конфигурации следует учитывать, что эти параметры могут задаваться:


'''segmented''': график строится по указанным в конфигурации значениям. Особенность: так как график будет выглядить как лесенка, то на разных промежутках, при разных значениях fullness, мы будем иметь одно и то же значение drop probability.
*'''segmented''': график строится по указанным в конфигурации значениям. Особенность: так как график будет выглядить как лесенка, то на разных промежутках, при разных значениях fullness, мы будем иметь одно и то же значение drop probability.


Пример конфига:
Пример конфига:
Строка 157: Строка 164:
  set class-of-service drop-profiles ''segmented'' fill-level 95 drop-probability 100
  set class-of-service drop-profiles ''segmented'' fill-level 95 drop-probability 100


'''interpolated''':  
*'''interpolated''':  


Представляет собой гладкий график, постепенно возвышающийся.
Представляет собой гладкий график, постепенно возвышающийся.


Строится автоматически, состоит из 64 координат, включая координаты, которые мы задали для построения кривой.
Строится автоматически, состоит из 64 координат, включая координаты, которые мы задали для построения кривой.
(0,0) (100,100) - эти координаты включены по умолчанию.


Пример конфига:
Пример конфига:
Строка 167: Строка 176:
  set class-of-service drop-profiles ''interpolated'' interpolate fill-level [50 75] drop-probability [25 50]
  set class-of-service drop-profiles ''interpolated'' interpolate fill-level [50 75] drop-probability [25 50]


'''Default settings'''
===Default settings===


  fill-level 0 drop-probability 0
  fill-level 0 drop-probability 0
Строка 174: Строка 183:
Вообще дефолтная настройка смысла не имеет, так как начинает отбрасывать пакеты только при полной загруженности буффера, что и без того происходит! )
Вообще дефолтная настройка смысла не имеет, так как начинает отбрасывать пакеты только при полной загруженности буффера, что и без того происходит! )


'''Apply drop profile'''
===Apply drop profile===


Помимо того что drop profile нужно создать, для его работы его нужно прикрепить к какой-нибудь очереди.
Помимо того что drop profile нужно создать, для его работы его нужно прикрепить к какой-нибудь очереди.
Строка 180: Строка 189:
Одной очереди может быть применено более 1 drop profile для разных типов трафика.
Одной очереди может быть применено более 1 drop profile для разных типов трафика.


Также drop profile придает значение для PLP. До этого PLP было просто меткой, прикрепленной к пакету.
Также drop profile придает значение для PLP. До этого PLP было просто меткой, прикрепленной к пакету. Я так понимаю, что здесь речь о том, то прикрепленный к пакету PLP теперь имеет значение и на его основании, в том числе, будет обработан трафик.


Также drop profile может быть назначен по protocol-specific: non-TCP, TCP, all traffic.
Также drop profile может быть назначен по protocol-specific: non-TCP, TCP, all traffic.


'''Drop profile map options'''
===Drop profile map options===


'''loss-priority''': ''low'', ''medium-low'', ''medium-high'', ''high''. ''any''
'''loss-priority''': ''low'', ''medium-low'', ''medium-high'', ''high''. ''any''
Строка 196: Строка 205:
По сути здесь выцепляется трафик из определенного forwarding-class, с определенным PLP, опеределнного протокола и к нему применяется определенный drop-profile.
По сути здесь выцепляется трафик из определенного forwarding-class, с определенным PLP, опеределнного протокола и к нему применяется определенный drop-profile.


'''Default scheduler settings'''
===Default scheduler settings===


  edit class-of-service schedule schedule-name drop-profile-map loss-priority any protocol any drop-profile terminal
  edit class-of-service schedule schedule-name drop-profile-map loss-priority any protocol any drop-profile terminal
Строка 202: Строка 211:
  set class-of-service drop-profiles terminal fill-level 100 drop-probability 100
  set class-of-service drop-profiles terminal fill-level 100 drop-probability 100


=== Scheduler configuration ===
=Scheduler map=
Используется для группирования сложных наборов schedulers, чтобы можно было применить их к каждому FW class на интерфейсе.


1. Configure scheduler, including drop profile
При создании scheduler map мы задаем кол-во сервисов, назначенных каждому FW class и соответствующих приоритетов.


a Transmission rate
При этом к одной очереди можно применить несколько FW class (queue). Далее трафик можно будет обрабатывать особым образом, основываясь на PLP.


b Queue priority
=Конфигурация Scheduler=


c Delay buffers
*Configure scheduler, including drop profile
 
:*Transmission rate
d Drop profile
:*Queue priority
 
:*Delay buffers
e Drop profile maps
:*Drop profile - не в рамках scheduler
 
:*Drop profile maps
2. Configure scheduler map
*Configure scheduler map: schedulers придуманы, чтобы определенным образом управлять определенным трафиком. Сами по себе schedulers ничего не делают, нужна привязка. Scheduler-map как бы линк между forw-class и scheduler.
 
*Apply scheduler map to an interface: будет работать в outbound направлении. Для port-level queueing вешается на физический интерфейс.
Schedulers придуманы, чтобы определенным образом управлять определенным трафиком. Сами по себе schedulers ничего не делают, нужна привязка. Scheduler-map как бы линк между forw-class и scheduler.
 
3. Apply scheduler map to an interface.
 
Будет работать в outbound направлении. Для port-level queueing вешается на физический интерфейс.


Пример:
Пример:
Строка 249: Строка 254:


  set class-of-service interfaces ge-0/0/0 scheduler-map ''sched-map-example''
  set class-of-service interfaces ge-0/0/0 scheduler-map ''sched-map-example''
=Дополнительная информация=
*[[Глава 5. Hierarchical scheduling]]
*[[Глава 1. QoS]]
*[[Глава 8. Packet flow]]

Текущая версия на 18:20, 15 июля 2021

Основы scheduling

С помощью классификатора определили трафик в разные очереди, теперь нужно как-то трафик обрабатывать. Этим процессом как раз занимается scheduler:

  • Порядок передачи пакетов
  • Скорость передачи пакетов
  • Кол-во пакетов, которое можно забуфферизировать
  • Разные способы обработки пакетов в случае заторов на сети.

Разная обработка трафика на основании loss-priority.

  • Классификация или полисер назначили PLP
  • PLP соответствует scheduling traffic profile
  • Traffic profile соответствует drop profile
  • Drop profile определяет вероятность отброса трафика

Port-based очереди (queues)

Каждый порт может содержать 4-8 очереди.

Одной очереди может быть назначено более одного forwarding class.

PQ-DWRR: priority queue deficit round-robin: механизм для выбора очереди и последующей передачи пакета. Priority - очереди обслуживаются в порядке, сконфигурированном для очередей.

WRED: Weighted random early detection: механизм для отброса пакетов. Основан на сконфигурированных параметрах: fw-class, PLP. С помощью него можно избежать и контролировать заторы.

Компонениы Scheduling

Transmission rate

Transmission rate - кол-во пропускной способности от физического интерфейса, выделенной для этой очереди. Похоже на CIR.

Очередь может превышать tranmission rate, если есть неиспользуемая полоса (использовать большую полосу, чем выделили изначально). Тут также используется терминология in-profile, out-of-profile.

edit class-of-service schedule <schedule-name> transmit-rate (rate | percent | remainder) exact | rate-limit
  • remainder - заполнение оставшегося буфера.
  • exact - буферизирует трафик, который превысил transm rate. При наличие неиспользуемой свободной полосы не будет давать очереди её использовать.
  • rate-limit - дропает трафик, который превысил transm rate.
  • no settings - очередь может превысить transm rate, если есть неиспользуемая полоса.

Есть значения по умолчанию. Так как по умолчанию в джуне созданы 2 fw-class (best-effort (0) и network-control (3)), то дефолтные параметры есть только для этих очередей.

Для best-effort - 95, для netw-control - 5.

Unusable bandwidth

В случае, когда у нас сформированы 2 очереди и trasm-rate между ними делится 50/20%, в таком случае получаем неиспользуемую полосу 30%.

Эта неиспользуемая полоса будет использоваться только очередями, у которых есть превышение transm-rate.

Scheduler будет делить неиспользуемую полосу между подходящими очередями.

Чтобы исключить очередь, используем exact или rate-limit в настройке.

Приоритет очереди

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

Значения:

  • Low
  • Medium-low
  • Medium-high
  • High
  • Strict-high - traffic always in-profile. Пакеты в этой очереди всегда в первую очередь используют необходимую полосу.

Остальные очереди передают трафик в порядке убывания приоритета от high к low.

Трафик в in-profile (по transmission rate) low priority, будет обрабатывается до трафика out-profile strict priority.

То есть сначала вне зависимости обрабатывается трафик в in-profile, только потом out-profile.

Но при этом, при передаче каждого пакета в очереди, ниже strict, происходит проверка - есть ли в очереди пакеты из более высокой очереди. Если есть, то начинают передаваться они, а потом продолжает передавать прежняя очередь (если за это время не набежало пакетов из тоже приоритетной очереди).

Strict-priority - опсана! она может сожрать всю полосу и остальные очереди могут "голодать". Но High-prioroty делит полосу с Strict.

Чтобы не происходило голодания, мы можем:

  1. также важным очередям назначать high-priotity.
  2. для strict-priority задавать в transm-rate rate-limit.

Разрешается задавать 1 strict-priority на 1 интерфейс.

edit class-of-service schedule <schedule-name> priority < high / low / medium-high / medium-low / strict-high >

Дефолтные значения для дефолтных fw-class: best-effort - low , network-control - low .

Delay buffers

- Delay buffers - кол-во данных, кот можно хранить.

larger buffer = many packet stores = large supported latency.

Buffer size - это параметр, определяющийся размер буфера интерфейса и также зависит от платформы.

edit class-of-service schedule <schedule-name> buffer-size <percent | temporal | remainder>

percentage: буфер "эластичный", когда очередь начинает использовать бОльшую полосу, чем ей было выделено изначально (transm-rate), буфер будет автоматически увеличиваться.

effective delay buffer (ms) = buffer size (%) * max port buffer size (ms)
effective delay buffer (s) * interf bandwidth (Mbps) / 8 = buffer size (MB) [используется для конвертации в Мбайты]

Пример:

100 ms - max buffer size
1GB ports
для очереди 0 - задаем percentage = 30%: effective delay buffer = 30 ms, buffer size = 0,03 s * 1000 Mbps /8 = 3,75 MB
для очереди 1 - задаем percentage = 45%: effective delay buffer = 45 ms, buffer size = 0,045 s * 1000 Mbps /8 = 5.625 MB

temporal: для задания размера такого буфера используются мс. Буфер не эластичный, имеет строгий верхний лимит и дропает весь трафик, превышающий этот лимит. Для вычисления оптимального размера буфера используется значение transmission-rate.

buffer size (MB) = max buffer size (s) * transmit rate (Mbps) / 8
buffer size (MB) = max buffer size (s) * [interface bandw (Mbps) * transmit rate (%)] / 8

Пример:

100 ms - max buffer size
1GB ports
для очереди 2 - задаем transmission rate = 100 Mbps (10%): buffer size = 0,1 * 100 Mbps / 8 = 1,25 MB
для очереди 2 - задаем transm rate = 10% : buffer size = 0,1 * 1000 Mbps * 0.1 / 8 = 1,25 MB
для очереди 3 - задаем transmission rate = 300 Mbps (30%): buffer size = 0,1 * 300 Mbps / 8 = 3,75 MB
для очереди 3 - задаем transm rate = 30% : buffer size = 0,1 * 1000 Mbps * 0.3 / 8 = 3,75 MB
 

remainder: использует все не занятое другими очередями пространство.

Когда мы выставляем buffer size и transm rate в процентном соотношении, хорошей практикой считается выставлять пропорциональные (равные) значения, но это не обязательно вообще.

В обоих случаях размер буффера будет увеличиваться при увеличении transm rate.

Default scheduler settings: Для best-effort - 95 , для netw-control - 5 , что равно дефолтным значениям transm-rate.

Drop profiles (RED/WRED)

RED drop profiles (random early discard) - как отбрасывать трафик, когда возникает запор. Работает напрямую с буфферами. Отбрасывание пакетов зависит от заполненности буфера.

Определяет параметры отброшенного трафика, назначает PLP для использования (set on a packet at ingress).

При этом в RED из-за "случайно отброшенных" пакетов может возникнуть такая ситуация, когда некоторые пакеты одного потока будут отброшены, тогда source перестанет получать acknowledgement от receiver. При этом затор на уже почти перегруженном линке будет только увеличиваться.

В связи с этим более эффективно использовать WRED, он полностью не уберет проблему с "нечестным" отбросом пакетов из одного потока, но хотя бы можно исключить подобную ситуацию для трафика, нетерпимого к подобным потерям. О нем дальше.

Параметры WRED

  1. fullness: наполненность буффера.
  2. drop probability: вероятность, что пакет будет отброшен.

Для drop-profile задаём значения для этих двух параметров. По сути получается линия на графике, где соотносятся fullness (%) к drop probability (%).

How it works:

  1. Для каждого пакета в очереди маршрутизатор назначает любое число от 0-100.
  2. Числа нанесены на график отношения fullness к drop probability (по оси fullness).
  3. Когда случайный номер выше линии, пакет передается.
  4. Когда случайный номер ниже линии, пакет дропается.

Чтобы сделать более тонкую обработку трафика, рекомендуется создать несколько drop pofiles с разной "агрессивностью", и применять каждый к разному типу трафика.

Такой подход является более взшешанным (weighted RED = WRED).

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

Когда мы настраиваем drop profile таким образом, что fullness < 100%, drop probability = 100%, мы таким образом уменьшаем эффективный максимальный размер буффера. То есть с помощью drop-profile мы можем влиять на "рабочий" размер буфера.

Config options

Помимо drop probability и fullness при конфигурации следует учитывать, что эти параметры могут задаваться:

  • segmented: график строится по указанным в конфигурации значениям. Особенность: так как график будет выглядить как лесенка, то на разных промежутках, при разных значениях fullness, мы будем иметь одно и то же значение drop probability.

Пример конфига:

set class-of-service drop-profiles segmented fill-level 25 drop-probability 25 
set class-of-service drop-profiles segmented fill-level 50 drop-probability 50
set class-of-service drop-profiles segmented fill-level 75 drop-probability 75
set class-of-service drop-profiles segmented fill-level 95 drop-probability 100
  • interpolated:

Представляет собой гладкий график, постепенно возвышающийся.

Строится автоматически, состоит из 64 координат, включая координаты, которые мы задали для построения кривой.

(0,0) (100,100) - эти координаты включены по умолчанию.

Пример конфига:

set class-of-service drop-profiles interpolated interpolate fill-level [50 75] drop-probability [25 50]

Default settings

fill-level 0 drop-probability 0
fill-level 100 drop-probability 100

Вообще дефолтная настройка смысла не имеет, так как начинает отбрасывать пакеты только при полной загруженности буффера, что и без того происходит! )

Apply drop profile

Помимо того что drop profile нужно создать, для его работы его нужно прикрепить к какой-нибудь очереди.

Одной очереди может быть применено более 1 drop profile для разных типов трафика.

Также drop profile придает значение для PLP. До этого PLP было просто меткой, прикрепленной к пакету. Я так понимаю, что здесь речь о том, то прикрепленный к пакету PLP теперь имеет значение и на его основании, в том числе, будет обработан трафик.

Также drop profile может быть назначен по protocol-specific: non-TCP, TCP, all traffic.

Drop profile map options

loss-priority: low, medium-low, medium-high, high. any

protocol: tcp, non-tcp, any

drop profile: desired drop-profile.

edit class-of-service schedule schedule-name drop-profile-map loss-priority ... protocol ... drop-profile ...

По сути здесь выцепляется трафик из определенного forwarding-class, с определенным PLP, опеределнного протокола и к нему применяется определенный drop-profile.

Default scheduler settings

edit class-of-service schedule schedule-name drop-profile-map loss-priority any protocol any drop-profile terminal
set class-of-service drop-profiles terminal fill-level 100 drop-probability 100

Scheduler map

Используется для группирования сложных наборов schedulers, чтобы можно было применить их к каждому FW class на интерфейсе.

При создании scheduler map мы задаем кол-во сервисов, назначенных каждому FW class и соответствующих приоритетов.

При этом к одной очереди можно применить несколько FW class (queue). Далее трафик можно будет обрабатывать особым образом, основываясь на PLP.

Конфигурация Scheduler

  • Configure scheduler, including drop profile
  • Transmission rate
  • Queue priority
  • Delay buffers
  • Drop profile - не в рамках scheduler
  • Drop profile maps
  • Configure scheduler map: schedulers придуманы, чтобы определенным образом управлять определенным трафиком. Сами по себе schedulers ничего не делают, нужна привязка. Scheduler-map как бы линк между forw-class и scheduler.
  • Apply scheduler map to an interface: будет работать в outbound направлении. Для port-level queueing вешается на физический интерфейс.

Пример:

scheduler

set class-of-service drop-profiles relaxed interpolate fill-level [75 90 100] drop-probability [0 75 100]
set class-of-service drop-profiles aggressive interpolate fill-level [50 75 90 100] drop-probability [0 50 75 100]
set class-of-service schedulers sch-be transmit-rate percent 70
set class-of-service schedulers sch-be buffer-size percent 70
set class-of-service schedulers sch-be priority low
set class-of-service schedulers sch-be drop-profile-map loss-priority high protocol any drop-profile aggressive
set class-of-service schedulers sch-be drop-profile-map loss-priority low protocol any drop-profile relaxed
set class-of-service schedulers sch-pri transmit-rate percent 30
set class-of-service schedulers sch-pri buffer-size percent 30
set class-of-service schedulers sch-pri priority high

scheduler map

set class-of-service scheduler-maps sched-map-example forwarding-class best-effort-data scheduler sch-be
set class-of-service scheduler-maps sched-map-example forwarding-class priority-data scheduler sch-pri

apply to an interface

set class-of-service interfaces ge-0/0/0 scheduler-map sched-map-example

Дополнительная информация