Защищаемся маршрутизатором: QoS. Диспетчер трафика qos


Как использовать QoS для обеспечения качества доступа в интернет

01.12.2016 | Владимир Хазов

*-По материалам www.howtogeek.com

Не весь интернет-трафик одинаково важен. Онлайн-видео без замираний картинки или звонок по Skype без заикания голоса важнее, чем загрузка большого файла с помощью торрент-клиента. Функция обеспечения качества обслуживания (QoS) маршрутизатора, шейпера или системы глубокого анализа трафика (DPI) позволяет расставлять приоритеты, какой трафик важнее, и предоставлять ему большую часть полосы пропускания.

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

Что такое качество обслуживания (QoS)

Функция обеспечения качества обслуживания – отличный, но редко используемый инструмент, с помощью которого можно определять приоритеты для различных видов трафика, а с помощью систем DPI даже для определенных приложений, деля между ними полосу пропускания в разных пропорциях. Правильная настройка правил QoS обеспечит гладкое проигрывание онлайн-видео, в то время как загружается большой файл, или быстрый веб-браузинг, пока дети играют в онлайн-игры.

Подключение к интернету можно сравнить с больницей, в которой полоса пропускания – это число врачей для лечения пациентов, больные являются приложениями, а медсестра – маршрутизатором, который их распределяет.

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

То же самое происходит в домашней сети или сети провайдера. Пропускная способность канала связи выдается равномерно в рамках тарифного плана, без учета важности каждого приложения. К примеру, если вы разговариваете по Skype, а в это время ваши дети запустят кино Netflix, качество звонка резко ухудшится. Интернет-провайдер, в свою очередь, ограничен скоростью канала к вышестоящему оператору связи, и его полосы пропускания может не хватить, чтобы обеспечить качество соединения, если все пользователи одновременно начнут качать файлы через торрент-клиент на максимальной скорости.

Маршрутизатор делит полосу поровну между всеми, не выделяя приоритета какому-либо виду трафика.

Возвращаясь к нашему сравнению с больницей, качество обслуживания – это компетентная медсестра, которая распределяет пациентов между врачами наиболее эффективным способом: пострадавшим в аварии займутся несколько специалистов, а человек с ушибом дождется одного доктора, когда тот освободится.

В сети с функцией качества обслуживания приоритет будет у того приложения или сервиса, который вы самостоятельно определите (онлайн-видео, IPTV, онлайновые игры и т. п.), оно получит большую скорость и минимальные задержки.

Как включить QoS

Существуют сотни различных маршрутизаторов –домашних и офисных, а также сложных устройств операторского класса. Не каждый из них имеет функцию QoS, а если имеет, то ее реализация может отличаться по спектру возможных настроек. Некоторые могут определять только приоритет между устройствами, некоторые – выделять определенные типы трафика (например, видео или голосовую связь), системы DPI способны распознать приложения, не использующие для обмена данными заранее известные заголовки и структуры данных, вносить изменения в поле приоритета проходящих через него пакетов для дальнейшего применения правил QoS.

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

Первый шаг: определить цель

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

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

Оператор связи использует QoS для достижения более глобальных целей:

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

Но принципы их достижения схожи с домашней сетью: определение приоритетных видов трафика и приложений, настройка правил в зависимости от приоритета и времени действия.

Второй шаг: определить скорость интернета

Для оператора связи скорость интернета – это скорость доступа к вышестоящему провайдеру (Uplink) или к нескольким провайдерам. Эта величина фиксированная и распределяется между всеми абонентами согласно их тарифным планам. Задачу ее оптимизации и грамотного распределения должны решать правила QoS для обеспечения удовлетворенности клиента от получаемой услуги.

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

Чтобы получить реальную картину, вам необходимо закрыть на компьютере все приложения, которые создают нагрузку на сеть, подключить его к роутеру медным кабелем. Технология беспроводной сети Wi-Fi, особенно если она работает не по современным протоколам Wireless N или Wireless AC, может быть узким местом полосы пропускания. Измерения могут показать скорость в 40 Мб/с вместо доступных 75 Мб/с именно из-за ограничений скорости беспроводной передачи данных.

Зайдите на сайт www.speedtest.net и нажмите кнопку «Начать проверку». Полученный результат необходимо перевести из «Мбит/с» в «Кбит/с», так как настройки QoS чаще всего задаются в этих единицах. Это можно сделать, умножив полученные значения на 1000.

В данном примере мы получили входящую скорость 42 900 Кбит/с, а исходящую – 3980 Кбит/с. Именно эти значения можно распределять между пользователями и приложениями в сети.

Третий шаг: включить QoS на роутере 

Невозможно описать порядок включения QoS на всех роутерах, так как каждый производитель предоставляет пользователю свой интерфейс управления, а сетевые устройства операторского класса, такие как Cisco, Juniper, Huawei, настраиваются из командной строки.

В большинстве случаев вам потребуется зайти на страницу управления устройством (набрать в браузере его адрес, чаще всего это 192.168.1.1), ввести логин и пароль администратора, которые указаны в руководстве пользователя, и перейти в раздел NAT сетевых настроек, вкладку QoS. Выберите Enable напротив функции Start QoS, порт для применения правил – WAN (порт соединения с провайдером), настройки входящей и исходящей скорости (downlink и uplink) должны указываться в размере 85–90 % от измеренной во втором шаге.

Пониженное значение скоростей указывается для того, чтобы дать обработчику QoS пространство для маневров, только так он работает эффективно. Теперь функция качества обслуживания включена и необходимо настроить правила приоритизации.

Как приоритизировать трафик

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

Операторы связи настраивают правила исходя из данных, полученных от инструментов аналитики систем DPI, которые показывают узкие места полосы пропускания и тренды, зависящие от времени суток. Некоторые домашние устройства имеют готовые предустановки, которые пользователь должен использовать для приоритизации.

Если же роутер позволяет производить ручные настройки приоритетов, вам необходимо задать их «вилки» в процентах от общей полосы пропускания:

  • Maximum: 60–100 %
  • Premium: 25–100 %
  • Express: 10–100 %
  • Standard: 5–100 %
  • Bulk: 1–100 %

Эти параметры определяют значение пропускной способности для конкретного устройства или приложения. Например, установив для приложения Maximum, вы назначаете ему использовать 60 % от полосы пропускания во время загрузки сети и 100 %, если сеть полностью доступна. Если установить «Магистральный», то, когда сеть свободна, приложение может использовать любую скорость полосы пропускания, но, если появляется нагрузка, оно получит лишь 1 %.

Хотим напомнить, что к приоритизации надо подходить с четким пониманием того, что вы хотите ограничить.

Варианты приоритизации

1. Приоритет сервиса или приложения

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

2. Приоритет интерфейса

Интерфейс в данном случае – это метод, по которому ваши устройства подключаются к сети. Вы можете настроить более высокий приоритет устройствам, которые подключаются по проводу, или устройствам беспроводной сети, или, наоборот, уменьшить приоритет гостевых устройств.

3. Приоритет устройств по IP-адресу

Вы можете назначить более высокий приоритет определенному устройству вашей сети по его IP-адресу (статическому или зарезервированному динамическому), тем самым обеспечить его более высокой скоростью доступа по сравнению с другими.

4. Приоритет устройств по MAC-адресу

Если вы используете динамическую адресацию, вы все равно можете назначить высокий приоритет одному из устройств сети по его MAC-адресу, который является уникальным и сведения о котором можно получить либо из программного обеспечения, либо из этикетки на корпусе.

Тест и оценка

Самые главные правила в настройке QoS – это добавлять правила последовательно и не торопиться. Начать необходимо с самых глобальных, а затем настраивать отдельные приложения и сервисы. Если вы добились желаемого результата и QoS выполняет все ваши требования, необходимо сохранить конфигурацию в виде скриншотов или файла резервной копии на случай, если потребуется выполнить сброс роутера и восстанавливать настройки.

Убедиться в правильности работы правил можно запустив сервисы с высоким и низким приоритетом и сравнив их скорости, или запустить speedtest на устройствах сети с разными приоритетами и посмотреть, которое из них покажет больший результат.

Настройка QoS – более сложный процесс, чем базовая настройка роутера, а для оператора связи еще и дополнительные капитальные затраты для покупки платформы DPI, однако и результат позволит добиться более качественного доступа к сети Интернет, а также сэкономить финансы на покупке высокоскоростного канала связи.

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

Поделиться в социальных сетях

vasexperts.ru

Cisco QoS для самых маленьких

Я всегда считал Quality of Service (QoS) чем-то из разряда “не дадим войсу квакать, не дадим изображению по вкс развалиться”, однако более глубокое изучение вопроса, откровенно говоря, приятно удивило. Количество средств по манипуляции трафиком, а так же различные методы предоставления гарантированного качества канала нужным приложениям сразу дали понять – нахрапом эту крепость не взять.

С чем полезен и с чем помогает справиться QoS?
  • Маленькая пропускная способность канала – не всегда у нас на руках оказывается тот канал, который позволит и youtube в HD посмотреть и корпоративным приложениям работать адекватно.
  • Потеря критичных пакетов в следствии заторов.
  • Задержки (delay) – время, которое требуется пакету чтобы попасть от источника к получателю. Так, к примеру, 400ms RTT для голоса еще туда-сюда, а вот с значениями, которые превышают этот порог вы получите эффект накладывающегося голоса.
  • Джиттер (jitter) или изменение задержки с течением времени. Сейчас у вас 100ms, а через минуту 200ms. Поздравляю, у вас теперь 100ms jitter, который превращается в задержку просто потому, что железкам нужно держать пакет в буфере какое-то время для обеспечения плавности того же разговора.
Методы настройки QoS
  • Command Line Interface (CLI) – per interface конфигурация.
  • Modular QoS CLI (MQC) – аки ZBF позволяет группировать class map в policy map, policy map привязывать к service policy, а вот уже последнее можно и на интерфейс применить. 
  • Auto QoS – генерирует некий усредненный конфиг, который, конечно не one size fit all, но в некоторых случаях оказывается вполне работоспособным.
  • QoS Policy Manager (QPM) – централизованная поддержка QoS в вашей сети. Встроена в CiscoWorks.
Инструменты QoS
  • Классификация и группировка различных типов трафика.
  • Маркировка трафика за тем, чтобы другие устройства в сети могли бы распознать его.
  • Policing & shaping. Policing позволяет либо отбрасывать пакеты при превышении какого-либо значения, либо изменять маркировку. Shaping – метод размещения пакетов в очередях (i.e. FIFO, WFQ, CBWFQ) при достижении лимита.
Избежание заторов (congestion avoidance)
  • First-in First-out – как понятно из названия – кто первый встал, того и тапки. Пакеты помещаются в очередь, пока не будет исчерпана пропускная способность канала. При ее исчерпании заполняется буфер. Ну а если и он закончился, то пакеты попросту отбрасываются – tail drop.
  • Random Early Detection (RED) – RED занимается занятной штукой: как только ваш буфер начинает заполняться – “БАМ!” – в нем погибает случайный пакет. И чем быстрее заполняется буфер, тем агрессивнее работает этот механизм. На сколько я знаю Cisco не поддерживает его работу.
  • Weighted Random Early Detection (WRED) – занимается тем же, что и RED, но вместо содомии с случайными пакетами этот механизм выбирает жертв на основании маркировки пакетов и обозначенных заранее правил. “БАМ!” – и вместо пакета с voice трафиком погибает кусок картинки с redtube’a. Если пакеты заранее не были маркированы, то WRED превращается в RED.
Управление заторами

Управлять заторами можно помещая пакеты в очереди, позволяя наиболее приоритетному трафику покидать интерфейс в первую очередь, а наименее приоритетный трафик может и включения WRED дождаться, всякое бывает.

Увеличение эффективности
  • Сжатие (data compression).
  • Фрагментация канала и чередование (link fragmentation & interleaving) – допустим у нас имеется медленный канал (serial, ага) в который готовится просочиться сочный пакет, содержащий не особо важные данные. На момент когда передача будет начата будет в принципе не важно настроен ли QoS – сочный пакет с радостью займет все предоставленные ему 1500 байт и не пустит крошечный голосовой пакет не смотря не на что. LFI говорит примерно следующее – больше у нас не будет больших пакетов, крошечный пакет голоса, упакованный g.711 должен пролезть no matter what.
Modular QoS CLI

Class map – отвечают за классификацию трафика, позволяя отделить трафик и большим приоритетом от трафика с меньшим. i.e. я хочу выделить http трафик в отдельный класс class-map 2.

Policy map – говорит что делать с трафиком, включенным в входящие в него class map. i.e. я хочу маркировать http трафик определенным тэгом в policy-map 1 и я хочу лимитировать полосу пропускания для http трафика в 64kbps в policy-map 2.

Service policy – применяет policy map на интерфейсе для входящего или исходящего трафика. i.e. я хочу чтобы policy-map 1 маркировала исходящий http трафик на fa0/1, а policy map 2 лимитировала входящий на fa0/2. Одна и только одна service policy может существовать для каждого из направлений на каждом интерфейсе.

Настройка class map

Для class map существуют 2 критерия, по которым они будут работать – match-all (логическое И) и match-any (логическое ИЛИ). По умолчанию создается class-map match-all, означающий что все условия, занесенные в такой class map должны совпасить одновременно для того, чтобы class-map сработала.

R2(config)#class-map ICMP R2(config-cmap)#match protocol icmp R2(config-cmap)#match packet length min 200 max 400 R2(config-cmap)#do sh class-map Class Map match-all ICMP (id 1) Match protocol icmp Match packet length min 200 max 400 Class Map match-any class-default (id 0) Match any

Под действие этой class map попадет ICMP трафик с размером пакета от 200 до 400 байт.

Самые наблюдательные из вас успели заметить, что помимо созданной class map ICMP существует еще одна – default, под действие которой попадает весь трафик – это class map по умолчанию. Например мы можем описать голосовой трафик и написать для него определенное правило A, а весь остальной трафик, который нам не интересен, отправится автоматом в class-default и для него будет применено правило B.

Помимо протоколов можно допускать или не допускать к фильтрации сети, хосты, а так же гибко их совмещать в одной class-map с помощью ACL. i.e.:

R2(config)#access-list 10 remark mail servers R2(config)#access-list 10 permit 10.1.1.1 R2(config)#access-list 10 permit 10.1.1.2 R2(config)#class-map match-all MAIL_SRVRS R2(config-cmap)#match access-group 10 R2(config-cmap)#match protocol smtp

Под действие такой class map попадут ваши почтовые сервера и SMTP трафик. И на 25 и на 587 порт. Умный IOS сам разберется благодаря Network Based Application Recognition (NBAR).

Настройка policy map

Пришло время рассказать бездушной железке что делать с классифицированным таким образом трафиком. Единственная полезная вещь, которую можно сделать с policy map сразу после создания это добавить к нему class map:

R2(config)#policy-map LIMIT_ICMP R2(config-pmap)#? QoS policy-map configuration commands: class policy criteria description Policy-Map description exit Exit from QoS policy-map configuration mode no Negate or set default values of a command rename Rename this policy-map

А вот после применения class map как раз и начинается все веселье:

R2(config-pmap)#class ICMP R2(config-pmap-c)#? QoS policy-map class configuration commands: bandwidth Bandwidth compression Activate Compression drop Drop all packets estimate estimate resources required for this class exit Exit from QoS class action configuration mode netflow-sampler NetFlow action no Negate or set default values of a command police Police priority Strict Scheduling Priority for this Class queue-limit Queue Max Threshold for Tail Drop random-detect Enable Random Early Detection as drop policy service-policy Configure Flow Next set Set QoS values shape Traffic Shaping

Обратите внимание на изменившееся приглашение.

Бегло пробежимся по опциям:

  • bandwidth – гарантирует трафику минимальную полосу пропускания в случае возникновения затора (CBWFQ). Можно устанавливать значения либо жестко, либо в процентах. Последнее решение обладает большей гибкостью, так как позволяет использовать одну и ту же policy map на интерфейсах с разными значениями bandwidth. 
  • compression – включает сжатие TCP или RTP заголовков для данного трафика, снижая network overhead;
  • drop – отбрасывает все пакеты, попавшие под действие class map;
  • estimate – позволяет предопределять допустимые пределы задержек или потерь пакетов для данного типа трафика;
  • netflow-sampler – в том случае если вам не интересен 100% учет сетевого трафика посредством netflow можно настроить sampler, который будет отправлять 1 flow из n, таким образом снижая количество трафика, льющегося на ваши коллекторы.
  • policy / shape – гибкие функции по policing’у и shaping’у трафика;
  • priority – гарантирует полосу пропускания (LLQ). Тут внимательный читатель спросит LOLWUT?, покосится на bandwidth, потом снова на priority и снова на bandwidth в попытках найти различия. На самом деле они есть и не маленькие – priority позволяет назначать не только минимальную гарантированную полосу пропускания, но и одновременно максимальную. Более подробно о LLQ можно прочитать тут или, возможно, в следующих статьях.
  • queue-limit – команда, позволяющая указать или модифицировать количество пакетов, которые маршрутизатор сможет поместить в очередь.
  • random-detect – включает механизм WRED.
  • service-policy – позволяет указать другую policy map для построения иерархических (вложенных) политик.
  • set – устанавливает различные значения в QoS поля.

Хотелось бы еще раз повторить – это краткое описание опций, подробные разговор о которых является темой не для одной статьи.

Применение policy map

Нет ничего проще. В режиме конфигурации интерфейса с помощью команды service-policy укажите направление и название policy map. Не так уж и трудно, не так ли? ;)

Практика

Для того, чтобы разбавить унылую теорию давайте соберем небольшой стенд, запретив на r2 ICMP пакеты больше 700 байт по направлению к r3 из 192.168.1.0/24 сети, для ICMP пакетов размером от 300 до 700 выставим ограничение 8000bps.

R2(config)#access-list 1 permit 192.168.1.0 0.0.0.255 R2(config)#class-map match-all ICMP R2(config-cmap)# match access-group 1 R2(config-cmap)# match protocol icmp R2(config-cmap)# match packet length min 300 max 700 R2(config-cmap)#class-map match-all HUGE_ICMP R2(config-cmap)# match access-group 1 R2(config-cmap)# match protocol icmp R2(config-cmap)# match packet length min 701 R2(config-cmap)#policy-map ICMP_PMAP R2(config-pmap)# class ICMP R2(config-pmap-c)# police rate 8000 bps R2(config-pmap-c-police)# conform-action transmit R2(config-pmap-c-police)# exceed-action drop R2(config-pmap-c-police)# class HUGE_ICMP R2(config-pmap-c)# drop R2(config-pmap-c)#int fa0/1 R2(config-if)# service-policy output ICMP_PMAP R2(config-if)#^Z

и проверим эмпирическим путем на R1:

R1#ping 1.1.1.2 repeat 20 size 299 Type escape sequence to abort. Sending 20, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (20/20), round-trip min/avg/max = 12/40/52 ms R1#ping 1.1.1.2 repeat 20 si R1#ping 1.1.1.2 repeat 20 size 300 Type escape sequence to abort. Sending 20, 300-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds: !!!!!.!!!!!.!!!!!.!! Success rate is 85 percent (17/20), round-trip min/avg/max = 24/41/64 ms R1#ping 1.1.1.2 repeat 20 size 700 Type escape sequence to abort. Sending 20, 700-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds: !!.!!.!!.!!.!!.!!.!! Success rate is 70 percent (14/20), round-trip min/avg/max = 24/46/80 ms R1#ping 1.1.1.2 repeat 20 size 701 Type escape sequence to abort. Sending 20, 701-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds: .................... Success rate is 0 percent (0/20)

действительно, ICMP пакеты до 299 включительно без проблем пролезают, минуя всю маркировку через class map, ICMP пакеты от 300 до 700 байт начинают испытывать трудности, в результате установленного лимита “не более 8000 бит в секунду”, а ICMP пакеты свыше 701 байта просто и без затей отбрасываются.

На R2 с работой вашей политики можно ознакомиться следующим образом:

R2#sh policy-map interface fa0/1 FastEthernet0/1 Service-policy output: ICMP_PMAP Class-map: ICMP (match-all) 195 packets, 94730 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 1 Match: protocol icmp Match: packet length min 300 max 700 police: rate 8000 bps, burst 1500 bytes conformed 31 packets, 15334 bytes; actions: transmit exceeded 9 packets, 5226 bytes; actions: drop conformed 0 bps, exceed 0 bps Class-map: HUGE_ICMP (match-all) 53 packets, 62262 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 1 Match: protocol icmp Match: packet length min 701 drop Class-map: class-default (match-any) 1538 packets, 170844 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any

Исходную информацию о трафике для составления QoS политик можно собрать в реальном времени c помощью того же nbar:

R2(config)#int fa0/1 R2(config-if)#ip nbar protocol-discovery R2(config-if)#^Z R2#sh ip nbar protocol-discovery top-n 2 FastEthernet0/1 Input Output ----- ------ Protocol Packet Count Packet Count Byte Count Byte Count 5min Bit Rate (bps) 5min Bit Rate (bps) 5min Max Bit Rate (bps) 5min Max Bit Rate (bps) ------------------------ ------------------------ ------------------------ icmp 8333 8430 1003954 1093120 0 0 22000 22000 bgp 0 0 0 0 0 0 0 0 unknown 0 0 0 0 0 0 0 0 Total 8333 8430 1003954 1093120 0 0 22000 22000

Но куда кошернее делать это с помощью netflow.

twistedminds.ru

Управление QoS на платформе Windows

Привет.

QoS – целая пачка технологий, без которых современная сеть работает крайне плохо, а ряд задач не может выполнить вообще. Это и логики классификации трафика, и схема marking’а, когда данные помечаются путём помещения в заголовок канального или сетевого уровня соответствующих пометок, и управление логикой работы очередей, когда надо отправить несколько потоков данных через ограниченный по пропускной способности интерфейс, и шейпинг, и многие другие дисциплины, без которых целостная картина просто не получится. Фундаментально это изучается разве что на курсе Cisco QOS 2.5, да и то – в пять дней не всегда влезаем, материала там много.

Однако, сетевые настройки Windows в плане “глубже, чем просто айпишник назначить”, обычно являют собой что-то мистическое для администратора (да и для большинства тренеров Microsoft тоже, т.к. сетевые вопросы в авторизованных курсах Microsoft рассказываются крайне минималистично). Хотя ничего ужасного в сетевых технологиях нет, скорее, наоборот – зачастую бытует мнение, что “в Windows этого нет”, базирующееся на глубоком выводе о том, что говорящий это не нашёл за 10 секунд.

Попробуем разобраться.

Предположим, что Вы уже знаете сетевые технологии на базовом уровне, хотя бы слышали про ethernet, 802.1Q и формат IP-пакета. Если не слышали – имеет смысл послушать наш курс Cisco ICND1 3.0, это бесплатно. Конечно, лучше изучить QoS основательно, но это, в принципе, не строго необходимо для восприятия данного материала.

QoS в Windows Server 2012 и других версиях ОС

  • Включаем поддержку QoS в сетевой подсистеме Windows
  • Глобальные настройки QoS
  • Настраиваем политики QoS
  • IP Precedence, DSCP – что и как
  • WMM_AC и специфика 802.11-сетей
  • Взаимодействие политик QoS
  • Настройки QoS Packet Scheduler
  • Quality Windows Audio Video Experience (qWave) – что такое и нужен ли

Начнём.

Включаем поддержку QoS в сетевой подсистеме Windows

Для того, чтобы маркировать и CoS и ToS, у Windows есть специальный сетевой компонент, который так и называется – QoS Packet Scheduler. Установите его и включите на всех сетевых интерфейсах, на которых планируется управление QoS.

QoS для старых версий Windows – Windows XP и Windows Server 2003

Для поддержки QoS в NT 5.1 / NT 5.2 Вам также необходимо в явном виде включить поддержку маркировки ToS – по умолчанию там она выключена. Это делается путём изменения DWORD32 значения DisableUserTOSSetting у ключа реестра HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters на нуль. Если такого значения нет – создайте его и обнулите в явном виде, а после перезапустите систему – без этого параметр не применится и ОС будет продолжать игнорировать заданную приложениями через Winsock опцию IP_TOS.

Теперь продолжим про настройки, общие для разных версий Windows.

Если посмотреть внимательно, то этот компонент по сути и есть NDIS-драйвер:

Далее. Для того, чтобы мы могли указывать не только L3-параметры QoS (которые в IP-заголовке в поле ToS), а ещё и L2-параметры (которые в 802.1Q заголовке, в части, называемой 802.1p), нам надо включить на сетевом адаптере поддержку 802.1Q. Это будет выглядеть по разному в разных сетевых адаптерах – но примерно так:

Если такого пункта нет, то ставить метки CoS в кадре 802.3 некуда. Это уменьшит практическую пользу от настроек QoS, но, в общем-то, не уберёт её. Суть в том, что обычный хост не добавляет этот заголовок в 802.3-кадр, и эта настройка, в зависимости от сетевого адаптера, может обозначать разное – или “принимать кадры с 802.1Q-заголовком и анализировать его, в том числе и 802.1p”, или “делать это только в случае, когда мы отправляем кадр с меткой 802.1Q”. Смотрите детальнее специфику своего сетевого адаптера, общий совет тут выдать можно только один – если заголовка 802.1Q нет, то данные о качестве обслуживания можно добавить лишь в L3-заголовок.

Если Вы проделали всё вышеуказанное – система готова к тому, чтобы реализовывать заданные Вами параметры QoS. Теперь надо их задать.

Глобальные настройки QoS в Windows

Глобальные настройки QoS коснутся двух моментов – того, как будет обрабатываться входящий TCP-трафик, и того, как будут взаимодействовать политики QoS и установки QoS на уровне отдельных приложений. Находятся они в объекте групповой политики, точнее – в Computer Configuration / Windows Settings / Policy-based QoS, в контекстном меню Advanced QoS Settings…, вызываемом нажатием правой кнопки мыши. Рассмотрим их по отдельности.

Настройки Inbound TCP Traffic

Выглядеть они будут примерно так:

Это, по сути, никакой не QoS, а управление окном TCP для трафика в сторону данного хоста. Идея в том, что данная настройка напрямую влияет на то, какое максимальное значение receive window будет предлагаться при работе TCP-соединений. Начиная с NT 6.0, в Windows появилась человеческая поддержка окна TCP размером более 64К, вот данная политика и позволяет задать это максимальное значение окна централизованно. При задании уровня 0 окно будет ограничено 64КБ, при 1 – 256КБ, при 2 – 1МБ, а при 3 – 16МБ.

Учтите, что чем больше окно, тем реже TCP отправляет подтверждения о приёме, и тем менее “динамично” он реагирует на форс-мажорные ситуации, когда сегмент TCP задерживается или теряется. Чем меньше – тем быстрее реакция, но больше служебного трафика. В общем и целом в надёжных сетях при передаче больших объёмов данных (например, файл-сервер в локальной сети офиса) целесообразно устанавливать значение выше, а при сценарии “По tcp-сессии идёт не очень много данных, но у канала варьируется латентность и качество” – меньшее значение.

Настройки DSCP Marking Override

Выглядеть данные настройки будут так:

Это достаточно простая настройка, некий аналог mls qos trust cos в Cisco IOS. Суть – разрешать или нет приложениям, которые умеют метить трафик, делать это. Если выберете, что в явном виде можно – то когда приложение будет устанавливать поле ToS, то политики QoS будут игнорироваться, если нет – то наоборот; приложения на данном хосте будут безрезультатно вызывать функции API по маркировке трафика, а вся маркировка будет идти по явно указанной в политиках логике.

Давайте теперь посмотрим, как эти политики формируются.

Настраиваем политики QoS

Находятся они там же – Computer Configuration / Windows Settings / Policy-based QoS. Рассмотрим создание политики.

Первое, что надо учесть – ограничения политик. Под них может подпадать только трафик TCP и UDP. Другие IP-протоколы ограничить не получится. Плюс есть дополнительные настройки для HTTP-сессий, что улучшает ситуацию. Поэтому штатное решение по управлению качеством обслуживания затрагивает не весь возможный трафик, но в подавляющем большинстве случаев является достаточным. Приоритет исходящего IPSec или PPTP-трафика, например, задать не получится.

При создании политики первым делом надо будет указать её название (произвольное, технического назначения не имеет), значение DSCP и ограничение на полосу. Давайте чуток вспомним, что это и зачем.

QoS – это большая пачка технологий. Это и то, как помечать пакеты и кадры (Marking), и то, как формировать очереди для отправки нескольких потоков с разными метками через один интерфейс (Queuing), и то, как сбрасывать из этих очередей лишний трафик (Shaping). Когда речь идёт о сегменте сети, в котором эта логика единообразна и продумана (трафик X помечается на всех устройствах однотипно и однотипно же добавляется в очереди), говорят о том, что это – домен QoS. Мы будем рассчитывать на то, что установки, которые мы сейчас делаем через групповую политику, будут аналогично восприниматься сетевыми устройствами – это уже out of scope для этой статьи, но для полноценной поддержки QoS в организации это сделать нужно. Иначе нет никакого особого смысла тщательно классифицировать трафик, потом помечать, а потом на первом же коммутаторе в процессе отправки в uplink валить всё в одну кучу с логикой FIFO.

Когда деревья были большими – 31 год назад, в 1981 году – в заголовке IP-пакета тоже, как и сейчас, было одинокое поле размером с байт и с названием ToS – Type of Service. То, что делать с этим полем, написали в RFC 791 и назвали IP Precedence. Делать предлагалось многое – помечать каждый пакет “уровнем важности” от 0 до 7, используя 3 бита этого поля, и добавлять пожелания вида “если есть возможность, отправь трафик по каналу с меньшей латентностью / большей надёжностью / большей номинальной полосой пропускания”, используя ещё 3 бита. Два бита отложили до лучших времён. Как-то так:

[Бит приоритета N0 |Бит приоритета N1 |Бит приоритета N2 |Бит задержки |Бит толщины |Бит надёжности |Unused |Unused]

Потом ещё чуток подумали и задействовали дополнительный бит, добавив 4е пожелание – “чтобы через тот канал, который подешевле в плане денег” – RFC 1349. Итого остался один незадействованный бит, получилось 8 уровней приоритета трафика плюс 4 бита и их комбинации влияли на выбор “при прочих равных условиях”.

Предполагалось, что этого хватит. Стало так:

[Бит приоритета N0Бит приоритета N1Бит приоритета N2Бит нежелательной задержкиБит толщины (канала)Бит надёжностиПо любви или за деньгиUnused]

Хорошо заметно, что логическую модель пожеланий разрабатывала женщина.

Модель IP Precedence была простой и предполагала, что весь трафик можно разбить на 8 классов, между которыми будет простое логическое соотношение вида “5 всегда важнее, чем 4”, плюс добавить некоторые пожелания. Все задачи по реализации этой схемы (чтобы одинаковый трафик метили одинаковыми IP Precedence, и обрабатывали схожим способом, плюс учитывали пожелания в виде 4х дополнительных бит) ложились на администратора. Впоследствии 4 бита “пожеланий” практически перестали использовать, и схема IP Precedence превратилась в минималистичную “8 глобальных типов трафика, выстроеных по важности”. Их можно трактовать и называть по-разному, логики работы это не поменяет, например так:

  • 0 – То, что называется Best Effort – трафик, который будет доставляться по остаточному принципу, когда будет возможность. Best Effort – это не “наилучшим способом”, это “хотели, как лучше, а как получится – посмотрим”. Обычно 0 – это весь неклассифицированный трафик.
  • 1 – Распознаный трафик. Например, HTTP, SMB, FTP. Это не значит, что этот трафик какой-то особенный. Он хотя бы “понятно какой”.
  • 2 – Приоритетный трафик. Например, RDP – при перекачке файла будет не очень хорошо, если начнёт тормозить работа с терминальным сервером.

Но 14 лет назад, в 1998 году, парни из EMC и Cisco решили, что не хватит, и придумали ощутимо более гибкую систему, притом сразу и для ToS в IPv4, и для его потомка – Traffic Class в IPv6. Назвали её Differentiated Services. Система задействовала уже все 8 бит поля ToS – 6 на идентификатор класса (DSCP), и 2 на сигнализацию в случае заторов в сети (ECN). Как раз этот, более современный способ, и используется в политиках Windows. Метки, заданные по DSCP, более многочисленные, поэтому разбиваются на несколько групп.

DSCP-метки группы CS – Class Selector’ы

Этот механизм, который описан в RFC 2474, нужен для совместимости с предыдущей реализацией. В этом случае используется только 3 первые бита из 6, остальные устанавливаются в нули, поэтому с точки зрения расположения данных внутри байта ToS, CS’ы задают те же самые биты, что и IP Precedence. Соответственно, CS’ов будет 8 штук – от CS0 до CS7, и выглядеть они будут предсказуемо:

  • CS0 = 000 000
  • CS1 = 001 000
  • CS2 = 010 000
  • CS3 = 011 000
  • CS4 = 100 000
  • CS5 = 101 000
  • CS6 = 110 000
  • CS7 = 111 000

DSCP-метки группы AF – Assured Forwarding

Эти метки, логика которых есть в RFC 2597, уже интереснее – они содержат по 2 значения, x и y, поэтому записываются в читаемом варианте как AFxy.

Первое значение – x – будет обозначать класс трафика. Классов определено 4 – от единицы до четвёрки. Их иногда называют словами – единица = бронзовый, двойка = серебряный, тройка = золотой, четвёрка = платиновый. Это значение будет записано в первые 3 бита. Во вторые будет записан y – он будет обозначать приоритет при необходимости сброса трафика. Будет определено три значения – единица будет обозначать low drop priority, двойка – medium, тройка – high. Это будет обозначать, что трафик одного и того же класса, но с разными приоритетами, будет при возникновении ситуации удаляться исходя из этого приоритета – вначале low, потом medium, потом high. Не запутайтесь – пакет с high drop priority сбрасывается последним, а с low – первым.

Если сеть не поддерживает 3 приоритета, то она должна поддерживать хотя бы 2 – тогда они выглядят как AFx1 в роли “менее важного” и AFx2-AFx3 в роли “более важного”.

Определены следующие значения: 

  • AF11 = 001 010 (в десятичном варианте DSCP = 10)
  • AF12 = 001 100 (в десятичном варианте DSCP = 12)
  • AF13 = 001 110 (в десятичном варианте DSCP = 14)
  • AF21 = 010 010 (в десятичном варианте DSCP = 18)
  • AF22 = 010 100 (в десятичном варианте DSCP = 20)
  • AF23 = 010 110 (в десятичном варианте DSCP = 22)
  • AF31 = 011 010 (в десятичном варианте DSCP = 26)
  • AF32 = 011 100 (в десятичном варианте DSCP = 28)
  • AF33 = 011 110 (в десятичном варианте DSCP = 30)
  • AF41 = 100 010 (в десятичном варианте DSCP = 34)
  • AF42 = 100 100 (в десятичном варианте DSCP = 36)
  • AF43 = 100 110 (в десятичном варианте DSCP = 38)

DSCP-метка EF – Expedited Forwarding

Это – высший, “premium” класс обслуживания. Значение этой метки – 46, она обозначает трафик, который надо отправить самым лучшим по всем параметрам способом.

Вкратце всё. Как понятно, значение DSCP равное нулю будет обозначать Best-Effort доставку.

Специфика 802.11-сетей

У WiFi будет своя классификация типов трафика. Она будет называться WMM_AC (Wireless MultiMedia Access Categories) и будет достаточно несложной.

  1. Весь трафик с DSCP от 48 и выше относится к Voice-классу (обозначается как VO)
  2. Весь трафик с DSCP от 32 до 47 относится к Video-классу (обозначается как VI)
  3. Весь трафик с DSCP от 24 до 31 относится к BestEffort-классу (обозначается как BE)
  4. Весь трафик с DSCP от 8 до 23 относится к Background-классу (обозначается как BK)
  5. Весь трафик с DSCP от 0 до 7 относится (опять, да?) к BestEffort-классу (обозначается тоже как BE)

Соответственно, если Ваш WiFi-адаптер поддерживает WMM, то Вы можете включить это на уровне драйвера WiFi-адаптера, и он будет классифицировать свой исходящий трафик по 4м очередям в соответствии с “VO самый главный, VI второй, BE обычный, а BK – фоновый”. Если в Вашей сети политики QoS будут действовать на хосты с WiFi-адаптерами – учитывайте эти моменты при планировании политик.

Создаём политику

При создании политики мы можем указать нужный DSCP-класс и ограничение на полосу пропускания исходящего трафика, подпадающего под нужный критерий. Как оба этих значения, так и одно из них.

Применение политики на указанные приложения

Здесь есть три варианта – политика будет действовать на трафик от любого приложения, от указанного (указывается исполняемый модуль), или только на HTTP-ответы от наших приложений, подпадающих под нужные критерии. Третий вариант будет интересен, когда надо будет через политику ограничить полосу отдаваемого трафика для указанных HTTP-ресурсов – допустим, если мы хотим ограничить “отдаваемые с нас” видеофайлы, подпадающие под критерий вида “http://www.atraining.ru/video/*”.

Применение политики на указанные source/destination IPv4/IPv6-адреса

Достаточно тривиальные настройки – можно дополнительно ограничить применение политик QoS на трафик по L3-критерию. Замечу, что если в предыдущей настройке было выбрано “ограничить отдаваемый от нас в ответ на специфичный HTTP-запрос трафик”, то будет доступна только фильтрафия по destination, т.к. откуда исходит трафик и так понятно – от нас.

Применение политики на указанные source/destination TCP/UDP порты

Это просто – разве что не забудьте, что диапазон портов указывается через двоеточие (вида 1024:65535, а не 1024-65535).

В общем-то всё, политика создана. Можно создать и ещё. Как они будут взаимодействовать в случае пересечения?

Взаимодействие политик QoS

В случае, когда трафик будет подпадать под несколько политик, будет определяться “выигравшая”, приоритеты будут выставляться так:

  • Политики QoS уровня пользователя перекрывают политики QoS уровня компьютера
  • Если определена политика, влияющая на конкретное приложение, и есть политика, под которую тот же трафик подпадает, но уже по сетевым критериям (адреса, номера портов), то выигрывает политика приложения
  • Политика, действующая на настройку более конкретно, перекроет общую. Это отнесётся и к подпадению сразу под две политики сетевого плана (подпасть под 192.168.1.0/24 важнее, чем под 192.168.0.0/16), и под “указанный явно порт лучше чем диапазон портов”, и под “более конкретный URL вида http://host/video/* лучше, чем http://host/*”

Зафиксируйте также интересную штуку – на серверных ОС Microsoft настройки QoS применяются всегда, а на клиентских – только в случае, когда сетевой интерфейс для исходящего трафика распознан как Domain Network. Это сделано специально, чтобы ограничения, действующие на ноутбук сотрудника при работе в корп.сети, не ограничивали бы по скорости и качеству его работу во внешних сетях. Это не влияет на безопасность, поэтому не является ослаблением оной; это лишь ограничения исходящего трафика.

Теперь – о глобальных настройках “движка QoS” – сетевого компонента QoS Packet Scheduler.

Настройки QoS Packet Scheduler

Данные параметры будут указывать общесистемные (не относящиеся к конкретному типу трафика и сетевому интерфейсу) настройки этого механизма. Располагаться они будут в соответствующей ветке групповых политик:

Параметр QoS Packet Scheduler – Limit Outstanding Packets

Данная настройка указывает максимальный размер системной очереди исходящих пакетов. Т.е. если пакет назначен для отправки через конкретный интерфейс (найден next-hop и назначен egress interface), он считается “отправляемым” по данному критерию, и увеличивает этот счётчик на единицу. Как только пакет будет успешно отправлен (заметьте – именно пакет, этот счётчик работает только для L3-пакетов), счётчик уменьшится. Технически в Windows L3-очереди для конкретного интерфейса нет, есть только L2 (т.е. из кадров), поэтому если суммарное количество таких вот “ожидающих” пакетов будет больше указанного числа, то новый пакет не будет отправлен вообще, пока очередь не будет разгружена. От размера пакета это не зависит, считаются “головы” ожидающих пакетов. Пакеты всех сетевых протоколов (и IPv4, и IPv6) считаются вместе, т.е. при значении по умолчанию – 65536 – поставить “в очередь” по, допустим, 35 тысяч пакетов IPv4 и IPv6 не получится – 65537й пакет любого протокола будет отброшен по логике tail drop (т.е. не помещён в очередь).

Я бы рекомендовал помнить, что исходящий пакет лимитируется кадровым MTU, которое в случае включения поддержки Jumbo Frames на сетевых интерфейсах будет 9КБ, поэтому даже дефолтная настройка, по сути, выделяет буфер для ожидающих пакетов суммарным размером до 589.824.000 байт, т.е. более полугигабайта (в случае обычного сетевого интерфейса 10/100Мбит – поменьше, 98.304.000 байт). Этого более чем достаточно на все случаи жизни (просто подумайте, что это за приложение такое, которое будет пытаться впихнуть в исходящую очередь интерфейса столько пакетов), поэтому зачастую целесообразно это значение уменьшать – уменьшается объём RAM, занимаемый служебными структурами драйвера QoS Packet Scheduler. Я ставлю на хосты, у которых виртуальные сетевые интерфейсы и не-интенсивная нагрузка (например, DC/GC) значение в 4096, и footprint драйвера QoS проседает.

Для узлов, к которым подключается много внешних сессий, плюс настроен QoS, плюс отдаваемые данные состоят из мелких пакетов (голос, торренты) это значение может быть увеличено. Общая логика, думается, понятна – есть память и потребность отдавать очень много мелких пакетов – вполне можно и в ограничение в 65536 упереться.

Параметр QoS Packet Scheduler – Set Timer Resolution

В случае, когда настроено ограничение какого-либо типа исходящего трафика по полосе (“шейпинг”), данный параметр указывает то, какой минимальный квант времени используется для расчётов.

Логика проста – допустим, используется стандартное значение в 10ms. Это значит, что секунда делится на 100 равных частей. Допустим, есть правило, которое ограничивает сервис X по отправке до 5МБайт в секунду. Следовательно, 100 раз в секунду будет запускаться счётчик, который будет измерять трафик, фактически отправленный подпадающим под правило сервисом. Если этот трафик за учётный период в 10ms наберёт 50КБ, то больше он отправляться не будет и начнёт уходить в “ожидающую” очередь, про которую рассказано в предыдущем пункте. Ну а когда начнётся новый период в 10ms, опять сможет быть отправлено 50КБ.

Соответственно, чем это число больше, тем шейпинг будет “грубее”, но меньше будет тратиться процессорных ресурсов. А чем число меньше, тем более “гладко” будет уходить трафик – заметьте, это всё относится только к трафику, подпадающему под правила QoS, трафик без маркировки это затрагивать не будет. Имеет смысл увеличить разрешение таймера (до 2ms например) в случае, когда есть правило по отправке голосового трафика – это положительно повлияет на качество исходящего потока.

Параметр QoS Packet Scheduler – Limit Reservable Bandwidth

Самая страшная настройка – сколько про неё сказок рассказывается уже лет 10, просто ппц. Легенды о том, что “венда по дефолту 20% сетевой полосы пропускания просто так зажимает”, я слышал в десятках вариантов – от безобидного “потому что они тупые там и не могут нормально сетевуху полностью нагрузить” до шизоидного “это чтобы данные с винта пользователя в Пентагон отправлять”.

На самом деле всё просто. Это – суммарное количество резервируемой всеми правилами QoS, работающими на данной системе, полосы пропускания. Т.е. если оно 20%, а у Вас сетевой интерфейс в 100 Мбит, то как бы Вы не старались, и не создавали, например, 3 правила, каждое из которых резервирует под приложение по 15 мегабит (3*15=45), то Вы никак больше 20 мегабит не займёте в результате своим приоритезированным трафиком.

Грубо говоря, это значение показывает, сколько “QoS’овского классифицированного” трафика в процентах от номинальной полосы пропускания интерфейса может быть. Целесообразно, если Вы пишете политики QoS, увеличить это число например до 90%. Почему не до 100? Потому что в случае, когда по каким-то причинам весь трафик некоего приложения станет супер-приоритетным, и полоса резервирования будет 100%, другой трафик будет вечно проигрывать соревнование за очерёдность отправки, и система не сможет делать свои задачи – грубо говоря, например, отвалятся всякие служебные протоколы типа IKE, который ходит по 500му порту UDP, NTP, DNS, и прочие. Вот от этого идёт страховка, когда делают не 100, а не от того, что “винда просто так берёт и часть сети не использует”.

Quality Windows Audio Video Experience (qWave) – что такое и нужен ли

Данный компонент, появившийся со времен NT 6.0, представляет из себя клиент-серверный сервис, технически работающий по портам 2177 TCP/UDP, и нужный для того, чтобы две службы на разных хостах могли “договориться” о том, какому потоку данных какой приоритет предоставить. Сервер, инициирующий передачу данных, имеет роль initiator, принимающая сторона имеет роль sink. Суть в том, что приложение, которое сможет “заказать” у qWave уровень качества для своих данных, должно быть соответствующим способом разработано (например, использовать для установки сессии функционал .NET). qWave, по сути, будет перекрывать своими настройками, если они есть, системные. Плюсов у интегрированного подхода много – qWave автоматически определяет, поддерживается ли 802.1p не только на конечных хостах, но и на промежуточном сетевом оборудовании, позволяет гибко и на ходу переопределять резервируемую полосу для нужного трафика, а также постоянно отслеживать такие параметры, как latency канала (QoS Packet Scheduler этого делать не может), периодически отправляя тестовые пакеты и “промеряя” качество линии между двумя хостами.

Напомню – “просто так” установить этот компонент можно, но нужен софт, который будет уметь запросить у него функционал. По умолчанию qWave не работает, т.к. если бы он работал, то он тратил бы ресурсы сети на тестовые измерения качества канала.

Вместо заключения

Надеюсь, что эта краткая экскурсия в достаточно интересный мир управления трафиком была интересна и будет Вам полезна на практике.

Удач!

Дата последнего редактирования текста: 2013-10-03T14:52:56+00:00

Возможно, вам будет также интересно почитать эти статьи с нашей Knowledge Base

www.atraining.ru

Защищаемся маршрутизатором: QoS / Хабрахабр

QoS — тема большая. Прежде чем рассказывать про тонкости настроек и различные подходы в применении правил обработки трафика, имеет смысл напомнить, что такое вообще QoS.

Quality of Service (QoS) — технология предоставления различным классам трафика различных приоритетов в обслуживании.

Во-первых, легко понять, что любая приоритезация имеет смысл только в том случае, когда возникает очередь на обслуживание. Именно там, в очереди, можно «проскользнуть» первым, используя своё право. Очередь же образуется там, где узко (обычно такие места называются «бутылочным горлышком», bottle-neck). Типичное «горлышко» — выход в Интернет офиса, где компьютеры, подключенные к сети как минимум на скорости 100 Мбит/сек, все используют канал к провайдеру, который редко превышает 100 МБит/сек, а часто составляет мизерные 1-2-10МБит/сек. На всех.

Во-вторых, QoS не панацея: если «горлышко» уж слишком узкое, то часто переполняется физический буфер интерфейса, куда помещаются все пакеты, собирающиеся выйти через этот интерфейс. И тогда новопришедшие пакеты будут уничтожены, даже если они сверхнужные. Поэтому, если очередь на интерфейсе в среднем превышает 20% от максимального своего размера (на маршрутизаторах cisco максимальный размер очереди составляет как правило 128-256 пакетов), есть повод крепко задуматься над дизайном своей сети, проложить дополнительные маршруты или расширить полосу до провайдера.

Разберемся с составными элементами технологии

(дальше под катом, много)Маркировка. В полях заголовков различных сетевых протоколов (Ethernet, IP, ATM, MPLS и др.) присутствуют специальные поля, выделенные для маркирования трафика. Маркировать же трафик нужно для последующей более простой обработки в очередях.

Ethernet. Поле Class of Service (CoS) — 3 бита. Позволяет разделить трафик на 8 потоков с различной маркировкой

IP. Есть 2 стандарта: старый и новый. В старом было поле ToS (8 бит), из которого в свою очередь выделялись 3 бита под названием IP Precedence. Это поле копировалось в поле CoS Ethernet заголовка. Позднее был определен новый стандарт. Поле ToS было переименовано в DiffServ, и дополнительно выделено 6 бит для поля Differencial Service Code Point (DSCP), в котором можно передавать требуемые для данного типа трафика параметры.

Маркировать данные лучше всего ближе к источнику этих данных. По этой причине большинство IP-телефонов самостоятельно добавляют в IP-заголовок голосовых пакетов поле DSCP = EF или CS5. Многие приложения также маркируют трафик самостоятельно в надежде, что их пакеты будут обработаны приоритетно. Например, этим «грешат» пиринговые сети.

Очереди.

Даже если мы не используем никаких технологий приоритезации, это не значит, что не возникает очередей. В узком месте очередь возникнет в любом случае и будет предоставлять стандартный механизм FIFO (First In First Out). Такая очередь, очевидно, позволит не уничтожать пакеты сразу, сохраняя их до отправки в буфере, но никаких преференций, скажем, голосовому трафику не предоставит.

Если хочется предоставить некоторому выделенному классу абсолютный приоритет (т.е. пакеты из этого класса всегда будут обрабатываться первыми), то такая технология называется Priority queuing. Все пакеты, находящиеся в физическом исходящем буфере интерфейса будут разделены на 2 логических очереди и пакеты из привилегированной очереди будут отсылаться, пока она не опустеет. Только после этого начнут передаваться пакеты из второй очереди. Эта технология простая, довольно грубая, её можно считать устаревшей, т.к. обработка неприоритетного трафика будет постоянно останавливаться. На маршрутизаторах cisco можно создать 4 очереди с разными приоритетами. В них соблюдается строгая иерархия: пакеты из менее привилегированных очередей не будут обслуживаться до тех пор, пока не опустеют все очереди с более высоким приоритетом.

Справедливая очередь (Fair Queuing). Технология, которая позволяет каждому классу трафика предоставить одинаковые права. Как правило не используется, т.к. мало даёт с точки зрения улучшения качества сервиса.

Взвешенная справедливая очередь (Weighted Fair Queuing, WFQ). Технология, которая предоставляет разным классам трафика разные права (можно сказать, что «вес» у разных очередей разный), но одновременно обслуживает все очереди. «На пальцах» это выглядит так: все пакеты делятся на логические очереди, используя в качестве критерия поле IP Precedence. Это же поле задаёт и приоритет (чем больше, тем лучше). Дальше, маршрутизатор вычисляет, пакет из какой очереди «быстрее» передать и передаёт именно его.

Считает он это по формуле:

dT=(t(i)-t(0))/(1+IPP)

IPP — значение поля IP Precedence t(i) — Время, требуемое на реальную передачу пакета интерфейсом. Можно вычислить, как L/Speed, где L — длина пакета, а Speed — скорость передачи интерфейса

Такая очередь по умолчанию включена на всех интерфейсах маршрутизаторов cisco, кроме интерфейсов точка-точка (инкапсуляция HDLC или РРР).

WFQ имеет ряд минусов: такая очередизация использует уже отмаркированные ранее пакеты, и не позволяет самостоятельно определять классы трафика и выделяемую полосу. Мало того, как правило уже никто не маркирует полем IP Precedence, поэтому пакеты идут немаркированные, т.е. все попадают в одну очередь.

Развитием WFQ стала взвешенная справедливая очередь, основанная на классах (Class-Based Weighted Fair Queuing, CBWFQ). В этой очереди администратор сам задаёт классы трафика, следуя различным критериям, например, используя ACL, как шаблон или анализируя заголовки протоколов (см.NBAR). Далее, для этих классов определяется «вес» и пакеты их очередей обслуживаются, соразмерно весу (больше вес — больше пакетов из этой очереди уйдёт в единицу времени)

Но такая очередь не обеспечивает строгого пропускания наиболее важных пакетов (как правило голосовых или пакетов других интерактивных приложений). Поэтому появился гибрид Priority и Class-Based Weighted Fair Queuing — PQ-CBWFQ, также известный как, Low Latency Queuing (LLQ). В этой технологии можно задать до 4х приоритетных очередей, остальные классы обслуживать по механизму CBWFQ

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

Подробнее о настройках расскажу дальше.

Таким образом процесс предоставления качества обслуживания можно поделить на 2 этапа:Маркировка. Поближе к источникам.Обработка пакетов. Помещение их в физическую очередь на интерфейсе, подразделение на логические очереди и предоставление этим логическим очередям различных ресурсов.

Технология QoS — достаточно ресурсоёмкая и весьма существенно грузит процессор. И тем сильнее грузит, чем глубже в заголовки приходится залезать для классификации пакетов. Для сравнения: маршрутизатору гораздо проще заглянуть в заголовок IP пакета и проанализировать там 3 бита IPP, нежели раскручивать поток практически до уровня приложения, определяя, что за протокол идёт внутри (технология NBAR)

Для упрощения дальнейшей обработки трафика, а также для создания так называемой «области доверия» (trusted boundary), где мы верим всем заголовкам, относящимся к QoS, мы можем делать следующее: 1. На коммутаторах и маршрутизаторах уровня доступа (близко к клиентским машинам) ловить пакеты, раскидывать их по классам 2.В политике качестве действия перекрашивать заголовки по-своему или переносить значения QoS-заголовков более высокого уровня на нижние.

Например, на маршрутизаторе ловим все пакеты из гостевого WiFi домена (предполагаем, что там могут быть не управляемые нами компьютеры и софт, который может использовать нестандартные QoS-заголовки), меняем любые заголовки IP на дефолтные, сопоставляем заголовкам 3 уровня (DSCP) заголовки канального уровня (CoS), чтобы дальше и коммутаторы могли эффективно приоритезировать трафик, используя только метку канального уровня.

Настройка LLQ

Настройка очередей заключается в настройке классов, затем для этих классов надо определить параметры полосы пропускания и применить всю созданную конструкцию на интерфейс.

Создание классов:

class-map NAME match?

access-group Access groupany Any packetsclass-map Class mapcos IEEE 802.1Q/ISL class of service/user priority valuesdestination-address Destination addressdiscard-class Discard behavior identifierdscp Match DSCP in IP(v4) and IPv6 packetsflow Flow based QoS parametersfr-de Match on Frame-relay DE bit fr-dlci Match on fr-dlci input-interface Select an input interface to matchip IP specific valuesmpls Multi Protocol Label Switching specific valuesnot Negate this match resultpacket Layer 3 Packet lengthprecedence Match Precedence in IP(v4) and IPv6 packetsprotocol Protocolqos-group Qos-groupsource-address Source addressvlan VLANs to match

Пакеты в классы можно рассортировывать по различным атрибутам, например, указывая ACL, как шаблон, либо по полю DSCP, либо выделяя конкретный протокол (включается технология NBAR)

Создание политики:

policy-map POLICY class NAME1 ?

bandwidth Bandwidthcompression Activate Compressiondrop Drop all packetslog Log IPv4 and ARP packetsnetflow-sampler NetFlow actionpolice Policepriority Strict Scheduling Priority for this Classqueue-limit Queue Max Threshold for Tail Droprandom-detect Enable Random Early Detection as drop policyservice-policy Configure Flow Nextset Set QoS valuesshape Traffic Shaping

Для каждого класса в политике можно либо выделить приритетно кусок полосы:

policy-map POLICY class NAME1 priority?

[8-2000000] Kilo Bits per secondpercent % of total bandwidth

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

Либо описать, какой «вес» имеет данный класс в рамках CBWFQ

policy-map POLICY class NAME1 bandwidth?

[8-2000000] Kilo Bits per secondpercent % of total Bandwidthremaining % of the remaining bandwidth

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

Возникает резонный вопрос: а откуда маршрутизатор знает ВСЮ полосу? Ответ банален: из параметра bandwidth на интерфейсе. Даже если он не сконфигурирован явно, какое то его значение обязательно есть. Его можно посмотреть командой sh int.

Также обязательно помнить, что по умолчанию вы распоряжаетсь не всей полосой, а лишь 75%. Пакеты, явно не попавшие в другие классы, попадают в class-default. Эту настройку для дефолтного класса можно задать явно

policy-map POLICY class class-default bandwidth percent 10

(UPD, спасибо OlegD) Изменить максимальную доступную полосу с дефолтных 75% можно командой на интерфейсе

max-reserved-bandwidth [percent]

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

Создаётся впечатление, что политика будет выдавать классам не больше, чем написано. Однако, такая ситуация будет лишь в том случае, если все очереди наполнены. Если же какая то пустует, то выделенную ей полосу наполненные очереди поделят пропорционально своему «весу».

Работать же вся эта конструкция будет так:

Если идут пакеты из класса с указанием priority, то маршрутизатор сосредотачивается на передаче этих пакетов. Причем, т.к. таких приоритетных очередей может быть несколько, то между ними полоса делится пропорционально указанным процентам.

Как только все приоритетные пакеты закончились, наступает очередь CBWFQ. За каждый отсчёт времени из каждой очереди «зачёрпывается» доля пакетов, указанная в настройке для данного класса. Если же часть очередей пустует, то их полоса делится пропорционально «весу» класса между загруженными очередями.

Применение на интерфейсе:

int s0/0 service-policy [input|output] POLICY

А что же делать, если надо строго рубить пакеты из класса, выходящие за дозволенную скорость? Ведь указание bandwidth лишь распределяет полосу между классами, когда очереди загружены.

Для решения этой задачи для класса трафика в политике есть технология

police [speed] [birst] conform-action [действие] exceed-action [действие]

она позволяет явно указать желаемую среднюю скорость (speed), максимальный «выброс», т.е. количество передаваемых данных за единицу времени. Чем больше «выброс», тем больше реальная скорость передачи может отклоняться от желаемой средней. Также указываются: действие для нормального трафика, не превышающего указанную скорость и действие для трафика, превысившего среднюю скорость. Действия могут быть такими

police 100000 8000 conform-action?

drop drop packetexceed-action action when rate is within conform and conform + exceed burstset-clp-transmit set atm clp and send itset-discard-class-transmit set discard-class and send itset-dscp-transmit set dscp and send itset-frde-transmit set FR DE and send itset-mpls-exp-imposition-transmit set exp at tag imposition and send itset-mpls-exp-topmost-transmit set exp on topmost label and send itset-prec-transmit rewrite packet precedence and send itset-qos-transmit set qos-group and send ittransmit transmit packet

Часто возникает также и другая задача. Предположим, что надо ограничить поток, идущий в сторону соседа с медленным каналом.

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

И тут мы сталкиваемся с одной очень важной вещью: для решения этой задачи надо сэмулировать «медленный» канал. Для этой эмуляции не достаточно только раскидать пакеты по очередям, надо ещё сэмулировать физический буфер «медленного» интерфейса. У каждого интерфейса есть скорость передачи пакетов. Т.е. в единицу времени каждый интерфейс может передать не более, чем N пакетов. Обычно физический буфер интерфейса рассчитывают так, чтобы обеспечить «автономную» работу интерфейсу на несколько единиц вермени. Поэтому физический буфер, скажем, GigabitEthernet будет в десятки раз больше какого-нибудь интерфейса Serial.

Что же плохого в том, чтобы запомнить много? Давайте рассмотрим подробно, что произойдёт, в случае если буфер на быстрой передающей стороне будет существенно больше буфера принимающей.

Пусть для простоты есть 1 очередь. На «быстрой» стороне сэмулируем малую скорость передачи. Это значит, что попадая под нашу политику пакеты начнут накапливаться в очереди. Т.к. физический буфер большой, то и логическая очередь получится внушительной. Часть приложений (работающих через ТСР) поздно получат уведомление о том, что часть пакетов не получена и долго будут держать большой размер окна, нагружая сторону-приемник. Это будет происходить в том идеальном случае, когда скорость передачи будет равна или меньше скорости приёма. Но интерфейс принимающей стороны может быть сам загружен и другими пакетами и тогда маленькая очередь на принимающей стороне не сможет вместить всех пакетов, передаваемых ей из центра. Начнутся потери, которые повлекут за собой дополнительные передачи, но в передающем буфере ведь ещё останется солидный «хвост» ранее накопленных пакетов, которые будут передаваться «вхолостую», т.к. на принимающей стороне не дождались более раннего пакета, а значит более позние будут просто проигнорированы.

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

Делается это командой

shape average [speed]

Ну а теперь самое интересное: а как быть, если мне помимо эмуляции физического буфера надо внутри него создать логические очереди? Например, выделить приоритетно голос?

Для это создаётся так называемая вложенная политика, которая применяется внутри основной и делит на логические очереди то, что в неё попадает из родительской.

Пришло время разобрать какой-нибудь залихватский пример на основе приведенной картинки.

Пусть мы собираеися создать устойчиво работающие голосовые каналы через интернет между CO и Remote. Для простоты пусть сеть Remote (172.16.1.0/24) имеет только связь с СО (10.0.0.0/8). Скорость интерфейса на Remote — 1 Мбит/сек и выделяется 25% этой скорости на голосовой трафик.

Тогда для начала нам надо выделить приоритетный класс трафика с обеих сторон и создать политику для данного класса. На СО дополнительно создадим класс, описывающий трафик между офисами

На СО:

class-map RTP match protocol rtp

policy-map RTP class RTP priority percent 25

ip access-list extended CO_REMOTE permit ip 10.0.0.0 0.255.255.255 172.16.1.0 0.0.0.255

class-map CO_REMOTE match access-list CO_REMOTE

На Remote поступим иначе: пусть в силу дохлости железа мы не можем использовать NBAR, тогда нам остаётся только явно описать порты для RTP

ip access-list extended RTP permit udp 172.16.1.0 0.0.0.255 range 16384 32768 10.0.0.0 0.255.255.255 range 16384 32768

class-map RTP match access-list RTP

policy-map QoS class RTP priority percent 25

Далее, на СО надо сэмулировать медленный интерфейс, применить вложенную политику для приоритезации голосовых пакетов

policy-map QoS class CO_REMOTE shape average 1000000 service-policy RTP

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

int g0/0 service-policy output QoS

На Remote установим параметр bandwidth (в кбит/сек) в соответствие со скоростью интерфейса. Напомню, что именно от этого параметра будет считаться 25%. И применим политику.

int s0/0 bandwidth 1000 service-policy output QoS

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

На более умных L2/3 коммутаторах на маршрутизируемых интерфейсах (т.е. либо на interface vlan, либо если порт выведен со второго уровня командой no switchport) применяется та же конструкция, что работает и на маршрутизаторах, а если порт или весь коммутатор работает в режиме L2 (верно для моделей 2950/60), то там для класса трафика можно использовать только указание police, а priority или bandwidth не доступны.

С сугубо защитной точки зрения, знание основ QoS позволит оперативно предотвращать бутылочные горла, вызванные работой червей. Как известно, червь сам по себе довольно агрессивен на фазе распространения и создаёт много паразитного трафика, т.е. по сути атаку отказа в обслуживании (Denial of Service, DoS).

Причем часто червь распространяется по нужным для работы портам (ТСР/135,445,80 и др.) Просто закрыть на маршрутизаторе эти порты было бы опрометчиво, поэтому гуманнее поступать так:

1. Собираем статистику по сетевому трафику. Либо по NetFlow, либо NBARом, либо по SNMP.

2. Выявляем профиль нормального трафика, т.е. по статистике, в среднем, протокол HTTP занимает не больше 70%, ICMP — не больше 5% и т.д. Такой профиль можно либо создать вручную, либо применив накопленную NBARом статистику. Мало того, можно даже автоматически создать классы, политику и применить на интерфейсе командой autoqos :)

3. Далее, можно ограничить для нетипичного сетевого трафика полосу. Если вдруг и подцепим заразу по нестандартному порту, большой беды для шлюза не будет: на загруженном интерфейсе зараза займет не более выделенной части.

4. Создав конструкцию (class-map — policy-map — service-policy) можно оперативно реагировать на появление нетипичного всплеска трафика, создавая вручную для него класс и сильно ограничивая полосу для этого класса.

Сергей Фёдоров

habrahabr.ru

Основы QoS (Quality of Service)

Попробуем разобраться, что такое QoS (Quality of Service), какие стандарты и определения к ней относятся. Поговорим о Best Effort Service, IntServ, DiffServ, PHB, ToS, CoS, IP Precedence (IPP), DSCP, AF, EF, Default PHB.

Давайте первым делом определимся, что же такое Quality of Service. Существует множество определений QoS, мне больше всего нравится вот это:

Под QoS (Quality of Service) следует понимать способность сети (сетевой инфраструктуры) обеспечить необходимый (требуемый) уровень сервиса заданному сетевуму трафику при использование различных технологий.

Под сервисом понимается множество параметров при передачи данных. Рассмотрим основные из них:

1. Bandwidth - ширина полосы пропускания. 2. End-to-end delay - задержка при передаче пакета. 3. Jitter - изменение задержки во времени при передаче пакетов. 4. Packet Loss – потеря (отбрасывание) пакетов при передачи данных.

Сервисные модели Quality of Service.

Существуют 3 различные сервисные моделей QoS.

1. Best Effort Service. Негарантированная доставка.

По сути, в этой модели отсутствуют какие-либо механизмы QoS. Используются все доступные ресурсы сети. Отсуствуют механизмы управления трафиком. Для улучшения QoS используется расширение полосы пропускания в узких местах, однако это не всегда даёт нужный эффект т.к. существуют типы трафика, чувствительные к задержкам и джиттеру (например VoIP).

2. Integrated Service (IntServ). Интегрированное обслуживание.

Обеспечивает сквозное (End-to-End) качество обслуживания, т.е. происходит резервирование ресурсов на всем пути прохождения трафиика. Для резирвирования ресурсов (Resource reservation) используется протокол RSVP, гарантируя необходимую пропускную способность. Существенным недостатком является постоянное резервирование ресурса, даже в том случае, если он не используется или используется не полностью.

3. Differentiated Service (DiffServ). Дифференцированное обслуживание.

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

DiffServ выпоняет две функции:

1. Формирование трафика на границах сети - функции классификации, маркировки пакетов и управление интенсивностью. 2. Политика пошагового обслуживания PHB (Per-Hop Behavior) включает функции распределения ресурсов и отбрасывания пакетов.

QoS Классификация и маркировка пакетов.

Начнем с определений:

Классификация пакетов (Packet Classification) - отнесение пакета к определенному классу.

Маркировка пакетов (Packet Marking) - установка требуемого приоритета.

Следует отметить, что классификация и маркировка пакетов отличаются в зависимости от уровня OSI, на котором работает устройство. Как правило, все коммутаторы работают на уровне L2, а именно с Ethernet кадрами. Маршутизаторы работают на уровне L3 и уже не с кадрами, а пакетами.

Классификация и маркировка пакетов на уровне L2

В протоколе Ethernet отсуствует возможность классификации и маркировки пакетов. Классификация возможна лишь по номеру входящего порта (что в большинстве случаев не представляет никакого интереса), а маркировка вообще невозможна.

Однако не все так плохо. Появился стандарт IEEE 802.1Q, описывающий технологию виртуальных локальных сетей VLAN, вместе с которым был разработан стандарт 802.1P для обеспечения QoS в сетях Ethernet (классификации и маркировки Ethernet кадров).

В стандарте 802.1P предусмотрено поле User Priority или второе более позднее название CoS (Class of Service), состоящее из 3-х бит в заголовке 802.1Q, т.е. CoS может принимать значения от 0 до 7.

Формат Ethernet кадра 802.1Q.

Ниже в таблицы собраны рекомендации по классификации и маркировке траффика согласно стандарту IEEE 802.1P.

Классы трафика согласно стандарту IEEE 802.1P.

Классификация и маркировка пакетов на уровне L3

На L3 мы имеем дело с протоколом IP (Internet Protocol). При разработке протокола IP для целей QoS было специально предусмотрено поле ToS (Type of Service) размером один байт.

Поле ToS может быть заполнен классификатором IP Precedence или DSCP в зависимости от задачи.

IP precedence (IPP) имеет размерность 3 бита, может принимать значения 0-7, т.е. можно говорить о 8-ми классах обслуживания. Изначально использовался классификатор IPP, но со временем появилась необходимость разделять трафиик на большее чем 8 классов обслуживания, следствием чего явилась разработка классификатора DSCP.

DSCP состоит из 6 бит (значения 0-63). Использование дополнительных 3-х бит позволяют ввести большее количество классов. DSCP обратно совместим с IPP. Важно понимать, что оборудование должно поддерживать обработку поля ToS заполненого классификатором DSCP, на старом оборудование с этим могут возникнуть проблемы.

Сравнение IPP и DSCP.

Per-Hop Behaviors (PHB)

Разберем более подробно понятие PHB.

Per-Hop Behaviors (PHB) - это политика пошагового обслуживания, иными словами, это некий алгоритм действий по обработки пакетов, выполняемый на каждом узле. PHB определяет, к какой из очередей отнести пакет, а также сброс пакетов в очереди в случае перегрузок.

Существуют 4 стандартизованных PHB.

1.Default PHB

Применяется для передачи Best-Efforts (негарантированая доставка) трафика, т.е. нет никакой маркировки, а точнее биты DSCP с 5 по 7 равны 000. Используется для совместимости с сетевыми устройствами, не поддерживающими маркировку или если она не используется.

Распределение бит DSCP в Default PHB.

2.Expedited Forwarding PHB (EF)

Используется для передачи трафика, чувствительного к задержкам. Биты DSCP с 5 по 7 равны 101. Пакеты, помеченные как EF, передаются с наименьшей задержкой в очереди.

Распределение бит DSCP в EF PHB.

3.Assured Forwarding PHB (AF)

Используется для гарантированной доставки. Значение бит DSCP с 5 по 7 может принимать 4 значения (001, 010, 011, 100), следовательно получается четыре стандартных класса AF (AF1, AF2, AF3, AF4), а внутри каждого класса может существует три уровня сбросса пакетов (low, medium, high).

Распределение бит DSCP в AF PHB.

aaa - номер класс обслуживания.dd - вероятность сброса пакета.

4.Class Selector PHB (CS)

Значение бит DSCP со 2 по 4 равны 000, что дает обратную совместимось с полем ToS, заполненым классификатором IPP.

Распределение бит DSCP в Class Selector PHB.

Ниже приведу таблицу сравнения DSCP и IP Precedence.

Сравнительная таблица DSCP и IPP.

Вот и все. Я попытался коротко рассказать о QoS и понятиях, входящих в него, таких как Best Effort Service, IntServ, DiffServ, PHB, ToS, CoS, IPP, DSCP, AF, EF, Default PHB.

Попробуем разобраться, что такое QoS (Quality of Service), какие стандарты и определения к ней относятся. Поговорим о Best Effort Service, IntServ, DiffServ, PHB, ToS, CoS, IP Precedence (IPP), DSCP, AF, EF, Default PHB.

Давайте первым делом определимся, что же такое Quality of Service. Существует множество определений QoS, мне больше всего нравится вот это:

Под QoS (Quality of Service) следует понимать способность сети (сетевой инфраструктуры) обеспечить необходимый (требуемый) уровень сервиса заданному сетевуму трафику при использование различных технологий.

Под сервисом понимается множество параметров при передачи данных. Рассмотрим основные из них:

1. Bandwidth - ширина полосы пропускания. 2. End-to-end delay - задержка при передаче пакета. 3. Jitter - изменение задержки во времени при передаче пакетов. 4. Packet Loss – потеря (отбрасывание) пакетов при передачи данных.

Сервисные модели Quality of Service.

Существуют 3 различные сервисные моделей QoS.

1. Best Effort Service. Негарантированная доставка.

По сути, в этой модели отсутствуют какие-либо механизмы QoS. Используются все доступные ресурсы сети. Отсуствуют механизмы управления трафиком. Для улучшения QoS используется расширение полосы пропускания в узких местах, однако это не всегда даёт нужный эффект т.к. существуют типы трафика, чувствительные к задержкам и джиттеру (например VoIP).

2. Integrated Service (IntServ). Интегрированное обслуживание.

Обеспечивает сквозное (End-to-End) качество обслуживания, т.е. происходит резервирование ресурсов на всем пути прохождения трафиика. Для резирвирования ресурсов (Resource reservation) используется протокол RSVP, гарантируя необходимую пропускную способность. Существенным недостатком является постоянное резервирование ресурса, даже в том случае, если он не используется или используется не полностью.

3. Differentiated Service (DiffServ). Дифференцированное обслуживание.

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

DiffServ выпоняет две функции:

1. Формирование трафика на границах сети - функции классификации, маркировки пакетов и управление интенсивностью. 2. Политика пошагового обслуживания PHB (Per-Hop Behavior) включает функции распределения ресурсов и отбрасывания пакетов.

QoS Классификация и маркировка пакетов.

Начнем с определений:

Классификация пакетов (Packet Classification) - отнесение пакета к определенному классу.

Маркировка пакетов (Packet Marking) - установка требуемого приоритета.

Следует отметить, что классификация и маркировка пакетов отличаются в зависимости от уровня OSI, на котором работает устройство. Как правило, все коммутаторы работают на уровне L2, а именно с Ethernet кадрами. Маршутизаторы работают на уровне L3 и уже не с кадрами, а пакетами.

Классификация и маркировка пакетов на уровне L2

В протоколе Ethernet отсуствует возможность классификации и маркировки пакетов. Классификация возможна лишь по номеру входящего порта (что в большинстве случаев не представляет никакого интереса), а маркировка вообще невозможна.

Однако не все так плохо. Появился стандарт IEEE 802.1Q, описывающий технологию виртуальных локальных сетей VLAN, вместе с которым был разработан стандарт 802.1P для обеспечения QoS в сетях Ethernet (классификации и маркировки Ethernet кадров).

В стандарте 802.1P предусмотрено поле User Priority или второе более позднее название CoS (Class of Service), состоящее из 3-х бит в заголовке 802.1Q, т.е. CoS может принимать значения от 0 до 7.

Формат Ethernet кадра 802.1Q.

Ниже в таблицы собраны рекомендации по классификации и маркировке траффика согласно стандарту IEEE 802.1P.

Классы трафика согласно стандарту IEEE 802.1P.

Классификация и маркировка пакетов на уровне L3

На L3 мы имеем дело с протоколом IP (Internet Protocol). При разработке протокола IP для целей QoS было специально предусмотрено поле ToS (Type of Service) размером один байт.

Поле ToS может быть заполнен классификатором IP Precedence или DSCP в зависимости от задачи.

IP precedence (IPP) имеет размерность 3 бита, может принимать значения 0-7, т.е. можно говорить о 8-ми классах обслуживания. Изначально использовался классификатор IPP, но со временем появилась необходимость разделять трафиик на большее чем 8 классов обслуживания, следствием чего явилась разработка классификатора DSCP.

DSCP состоит из 6 бит (значения 0-63). Использование дополнительных 3-х бит позволяют ввести большее количество классов. DSCP обратно совместим с IPP. Важно понимать, что оборудование должно поддерживать обработку поля ToS заполненого классификатором DSCP, на старом оборудование с этим могут возникнуть проблемы.

Сравнение IPP и DSCP.

Per-Hop Behaviors (PHB)

Разберем более подробно понятие PHB.

Per-Hop Behaviors (PHB) - это политика пошагового обслуживания, иными словами, это некий алгоритм действий по обработки пакетов, выполняемый на каждом узле. PHB определяет, к какой из очередей отнести пакет, а также сброс пакетов в очереди в случае перегрузок.

Существуют 4 стандартизованных PHB.

1.Default PHB

Применяется для передачи Best-Efforts (негарантированая доставка) трафика, т.е. нет никакой маркировки, а точнее биты DSCP с 5 по 7 равны 000. Используется для совместимости с сетевыми устройствами, не поддерживающими маркировку или если она не используется.

Распределение бит DSCP в Default PHB.

2.Expedited Forwarding PHB (EF)

Используется для передачи трафика, чувствительного к задержкам. Биты DSCP с 5 по 7 равны 101. Пакеты, помеченные как EF, передаются с наименьшей задержкой в очереди.

Распределение бит DSCP в EF PHB.

3.Assured Forwarding PHB (AF)

Используется для гарантированной доставки. Значение бит DSCP с 5 по 7 может принимать 4 значения (001, 010, 011, 100), следовательно получается четыре стандартных класса AF (AF1, AF2, AF3, AF4), а внутри каждого класса может существует три уровня сбросса пакетов (low, medium, high).

Распределение бит DSCP в AF PHB.

aaa - номер класс обслуживания.dd - вероятность сброса пакета.

4.Class Selector PHB (CS)

Значение бит DSCP со 2 по 4 равны 000, что дает обратную совместимось с полем ToS, заполненым классификатором IPP.

Распределение бит DSCP в Class Selector PHB.

Ниже приведу таблицу сравнения DSCP и IP Precedence.

Сравнительная таблица DSCP и IPP.

Вот и все. Я попытался коротко рассказать о QoS и понятиях, входящих в него, таких как Best Effort Service, IntServ, DiffServ, PHB, ToS, CoS, IPP, DSCP, AF, EF, Default PHB.

admin-gu.ru


Смотрите также