что такое dscp метки

Что такое dscp метки

Когда используют терминологию ToS, то в контексте приоретизации имеют в виду 3 старшие бита P2..P0, кодирующие уровень приоритета от 0 (минимальный приоритет) до 7 (максимальный приоритет). Для IP-телефонии применяется уровень приоритета 5 (critical, ToS-байт равен 0xA0 или 10100000b), а для обычного трафика уровень 0 (routine, ToS-байт равен 0x00 или 00000000b). У Cisco есть для каждого уровня приоритета специальное имя (precedence critical, precedence flash и т. д., см. таблицу).

IP Precedence Value

Эти коды используются также при назначении трафику маркировки, при конфигурировании policy-map:
!создается карта политики Police-GE0/1
policy-map Police-GE0/1
class Voice-GE0/1
priority 5000
set dscp ef
class Route-GE0/1
set dscp cs6
priority 1000
class Signal-GE0/1
set dscp cs3
priority 4500
class class-default
fair-queue

Когда используется термин CoS, то обычно имеется в виду перенос информации о приоритете на втором сетевом уровне L2 (MAC-адреса). При этом для кодирования приоритета используются 3 бита (получаются уровни от 0 до 7). Расположение этих бит в потоке данных зависит типа магистрального канала L2.

Источник

Реализация политик QoS с кодами DSCP

Параметры загрузки

Содержание

Общие сведения

В данном документе описывается процедура установки значений кода DSCP в настройках качества обслуживания (QoS) маршрутизаторов Cisco, а также анализируются связи между приоритетом IP и DSCP.

Предварительные условия

Требования

Необходимо обладать знаниями о заголовках IP-пакетов и об интерфейсе командной строки операционной системы Cisco IOS ®

Используемые компоненты

Сведения, содержащиеся в данном документе, не ограничены определенными версиями программного и аппаратного обеспечения.

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

Базовые сведения

Дифференцированные службы (DiffServ) — это новая модель, в которой трафик обрабатывается в промежуточных системах с учетом его относительной приоритетности, основанной на значении поля типа обслуживания (ToS). Описание модели DiffServ, которая заменяет исходные спецификации для определения приоритетности пакета (см. стандарт RFC 791 ), содержится в стандартах RFC 2474 и RFC 2475 . DiffServ увеличивает количество уровней приоритета, поддающихся определению путем перераспределения битов IP-пакета для маркировки приоритета.

Архитектура DiffServ подразумевает определение поля DiffServ (DS), которое заменяет поле типа обслуживания в протоколе IPv4, используемое при принятии решений о пересылке данных через каждый узел (PHB) для классификации пакетов и функций согласования трафика, например таких, как измерение, маркирование, формирование и контроль.

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

Условные обозначения

Дополнительные сведения об условных обозначениях см. в разделе «Технические рекомендации Cisco. Условные обозначения».

Код DSCP

Кодом DSCP называются шесть наиболее значимых бит поля DiffServ. Два последних неиспользуемых бита в поле DiffServ в рамках его структуры не определены, они в настоящее время используются в качестве битов явного уведомления о перегрузке (ECN). Оконечные маршрутизаторы классифицируют пакеты и присваивают им либо значение IP-приоритета, либо значение кода DSCP в сети Diffserv. Другие сетевые устройства в ядре, которое поддерживает Diffserv, используют значение DSCP в заголовке IP-пакета для выбора варианта пересылки данных пакета через каждый узел и обеспечивают адекватную обработку QoS.

На схемах в данном подразделе показаны различия между байтом ToS, определяемым стандартом RFC 791, и полем DiffServ.

Источник

Приоритет IP и значения DSCP в QoS (Quality of Service)

Рубрики:

Метки:

Рассмотрим, что такое приоритет IP и значения DSCP в QoS (Quality of Service). Одним из полей IP-пакета является поле «Тип обслуживания» (Type of Service field), также известное как байт TOS. Первоначальная идея байта TOS заключалась в возможности указать приоритет и запросить маршрут для обеспечения высокой пропускной способности, низкой задержки и высокой надежности обслуживания. Байт TOS был определен в 1981 году в RFC 791, но за эти годы способ его использования значительно изменился. В этой статье рассмотрим, что нужно знать о байте TOS, приоритете IP и значениях DSCP.

Для примера будет использоваться IP-заголовок со всеми его полями, включая байт TOS:

Примечание: Не стоит путать Type of Service (Тип обслуживания) и Class of Service (Класс обслуживания). TOS находится в заголовке IP-пакета (уровень 3), а COS — в заголовке 802.1Q (уровень 2) и используется для обеспечения качества обслуживания (QoS) по магистральным каналам.

Содержание:

Приоритет IP

Первоначально 8 битов байта TOS были определены следующим образом:

Первые 3 бита используются для определения приоритета (Precedence). Чем выше значение, тем важнее IP-пакет. В случае переполнения маршрутизатор прежде отбросит пакеты с меньшим приоритетом. Тип служебных битов TOS используется для определения того, какую задержку (delay), пропускную способность (bandwidth) и надежность (reliability) рассчитываем получить.

Ниже представлен список битов и возможных комбинаций:

Приоритет (Precedence):

Тип обслуживания (Type of Service):

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

Спустя 11 лет в 1992 году был создан RFC 1349, который поменял определение байта TOS, до следующего вида:

Первые 3 старших бита остались неизменными, но тип служебных битов изменился. Вместо 5 бит теперь используются только 4 бита для назначения TOS, а последний бит называется MBZ (Must Be Zero) — «должен быть нулем». Обычно этот бит не используется и маршрутизаторы игнорируют его, поскольку бит использовался только для экспериментов.

Тип служебных битов TOS выглядит следующим образом:

Дифференцированные услуги

Первые 6 битов поля DS используются для установки кодовой точки (codepoint), которая будет влиять на PHB (Per Hop Behavior) — политику пошагового обслуживания на каждом узле.

Кодовая точка — аналогична приоритету (precedence), используется для установки определенного приоритета.

Для понимания набора PHB представим сеть, состоящую из трёх расположенных подряд маршрутизаторов и двух телефонов в противоположных концах топологии:

Настройку QoS для определения приоритетности пакетов VoIP нужно выполнить на всех устройствах топологии. В то время, как R1 и R3 настроены на обработку приоритетов VoIP-пакетов, R2 продолжает рассматривать оставшиеся IP-пакеты. Не исключено, что R2 столкнётся с перегруженностью. И в связи с этим можно испытать проблемы с качеством телефонной связи.

Для исправной работы QoS необходимо настроить его как end-to-end (сквозное шифрование). Есть два способа это реализовать:

Резервирование — хороший вариант, поскольку есть гарантия, что сможем совершить телефонный звонок. Однако это не очень масштабируемое решение, потому как необходимо резервировать номера для каждого телефонного звонка. Что если один из маршрутизаторов потеряет информацию о резервировании? Идея использования резервирования для обеспечения сквозного QoS называется IntServ (Integrated Services) — «интегрированные услуги».

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

С 6 битами для кодовых точек (codepoints) можно создать множество разных приоритетов. Теоретически есть 64 возможных значения.

Идея, лежащая в основе PHB (Per Hop Behavior), заключается в том, что пакеты, помеченные конкретной кодовой точкой, получат определенную обработку QoS — например, организация очередей (queuing), контроль (policing) или формирование (shaping).

Базовый PHB (Default PHB)

Существуют сетевые узлы, которые не маркируют трафик. Чтобы они могли передавать данные по сети, используется значение пакета DSCP 000000. Этот пакет следует рассматривать как best effort — «негарантированная доставка».

Класс-селектор PHB (Class-selector PHB)

Ранее некоторые старые сетевые устройства поддерживали только IP-приоритет, а современные сетевые устройства использовали дифференцированные услуги (DiffServ). Чтобы убедиться, что они совместимы, можно применить кодовые точки выбора класса (class-selector codepoints):

В таком случае используются только первые 3 бита, как в поле с приоритетом IP. Ниже представлен список возможных кодовых точек выбора класса:

Обратите внимание, что CS1 — то же самое, что и «приоритет», а CS4 — Flash Override. Данную информацию можно использовать для совместимости между «старым» байтом TOS и «новым» полем DS.

Гарантированная пересылка PHB (Assured Forwarding PHB)

Приблизительно через год вышел RFC 2597, который описывает гарантированную пересылку (Assured Forwarding). Гарантированная пересылка AF PHB имеет две основные функции:

Существует 4 класса (class), и каждый из них будет помещён в свою очередь. Также в каждом классе существует вероятность сброса (drop probability) — когда очередь заполнена, пакеты с высокой вероятностью отбрасывания будут удалены из очереди раньше других пакетов. Всего есть 3 уровня для приоритета отбрасывания:

Первые 3 бита используются для определения класса (class), а следующие 3 бита используются для определения вероятности сброса (drop probability). Class 4 имеет самый высокий приоритет. Например, любой пакет из class 4 будет обработан лучше, чем пакет из class 3. Ниже приведены возможные значения:

Примечание: Некоторые поставщики предпочитают использовать десятичные значения вместо AF11, AF32 и т.д. Быстрый способ преобразования значения AF в десятичное значение заключается в использовании формулы 8x + 2y, где X = класс и Y = вероятность отбрасывания. Например, AF31 в десятичном виде – 8 x 3 + 2 x 1 = 26.

Ускоренная пересылка (Expedited Forwarding)

PHB EF (Expedited Forwarding) — «ускоренная пересылка», которая также имеет две функции:

Цель ускоренной пересылки EF — поместить пакеты в очередь, где они охватывают минимальную задержку и потерю пакетов. Для обеспечения этого используется приоритетная очередь (priority queue). Если в очереди с приоритетом есть пакеты, они будут отправлены раньше всех остальных очередей. Но есть вероятность того, что другие очереди не получат возможность отправлять свои пакеты, поэтому необходимо установить «ограничение скорости» для этой очереди. Делается это с помощью контроля (policing).

Значение DSCP обычно называется EF: в двоичном виде это 101110, десятичное значение 46.

Практическое применение

Много было рассказано о PHB (Per Hop Behavior), и слово Behavior («поведение») звучит так, будто при использовании определенного значения DSCP маршрутизатор автоматически ставит в очередь пакеты, отслеживает или отбрасывает их. Но это не так, поскольку необходимо настроить эти действия самостоятельно.

Есть много различных значений, которые можно использовать для байта TOS: приоритет IP, CS, AF и EF. Так что же действительно используется в сетях? Ответ прост — это действительно зависит от поставщика сетевых услуг. Значение приоритета IP 5 или DSCP EF обычно используется для голосового трафика. В то время как значение приоритета IP 3 или DSCP CS3 или AF31 применяется для сигнализации вызова.

Выводы

Спасибо за уделенное время на прочтение статьи. Теперь Вы знаете, что такое приоритет IP и значения DSCP в QoS.

Если возникли вопросы, задавайте их в комментариях.

Подписывайтесь на обновления нашего блога и оставайтесь в курсе новостей мира инфокоммуникаций!

Источник

Управление 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

Для того, чтобы маркировать и 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 ]

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

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

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

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 в роли “более важного”.

DSCP-метка EF – Expedited Forwarding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зафиксируйте также интересную штуку – на серверных ОС 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) – что такое и нужен ли

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

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

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

Источник