Существует такая служба как QoS . Расшифровывается сия аббревиатура, как Quality of Service . В случае настройки системы ее крайне нежелательно активировать, так как она имеет свойство существенно уменьшать пропускную способность сети (приблизительно на 20 процентов)
Сейчас, пожалуй, невозможно найти такого человека, который бы ни разу не читал ни одно из FAQ , касающихся работы Windows .
20% — это, разумеется, просто безумно много. И конечно же Майкрософт – должен погибнуть. Утверждения такого плана переходят из одного ФАКа в другой, бродят по форумам, средствам массовой информации, пользуются огромным успехом во всяких «твикалках» — программному обеспечению по «обучению» Windows . Раз облачать подобного рода утверждения необходимо крайне осторожно, этим-то мы сейчас и займемся, качественно применяя системный подход. То бишь крайне детально рассмотрим проблемный вопрос, будем опираться на авторитетные первоисточники.
Что есть сеть с качественным сервисом?
Предлагаем вам принять такое определение сетевой системы, которое максимально упрощено. Приложения начинают свою работу, делают ее на хостах и в результате своей деятельности меняются информацией друг с другом. Приложения шлют информацию ОС для передачи по сети. Как только нужная информация передается ОС, она автоматически становится сетевым трафиком.
QoS в свою очередь опирается на возможности сети обрабатывать такой трафик таким образом, чтобы точно выполнить запросы не одного, а сразу нескольких приложений. Это требует наличия базового механизма по переработке трафика из сети, который способен различать и классифицировать этот трафик, который имеет право на особенную обработку и право на управление самими механизмами.
Функциональные возможности этой службы созданы для того чтобы удовлетворять нескольких сетевых субъектов: во-первых, сетевых администраторов, а во-вторых, сами сетевые приложения. Зачастую, они имеют некоторые разногласия. Сетевой администратор стремится ограничить ресурсы, которые используются специфическим приложением, в то время как это же приложение стремится захватить как можно большее количество свободных ресурсов из сети. Интересы их могут согласовываться, если учитывать тот факто, что администратор сети будет играть самую главную роль, по отношению ко всем пользователям и приложениям.
Основные параметры службы QoS
Разные приложения имеют совершенно разные требования к переработке их трафика. Приложения в некоторой степени более или менее терпимы к потере и несущественным задержкам сетевого трафика.
Эти требования находят своё применение в таких параметрах, которые связанны с QoS :
Полоса пропускания (англ. Bandwidth) – та скорость с которой трафик, который генерируется приложением, может быть и должен быть передан по сети
Задержка (Latency) – время задержки, которое может допустить само приложение при доставке пакета информации
Изменение задержки (Jitter )
Потеря (Loss ) – коэффициент потери информации.
Если бы мы имели доступ к вечным ресурсам сети, то абсолютно весь трафик приложения мы могли бы распределять с нужной скоростью, с временем задержки, равным нулю, изменениями времени тоже равным нулю и с отсутствием каких-либо потерь. Но сетевые ресурсы далеко не вечны.
Механизм рассматриваемой службы держит под контролем распределение ресурсов сети длятрафика приложения, для того чтобы выполнить необходимые условия для его передачи.
Базовые ресурсы службы QoS и способы обработки трафика
Сети, которые занимаются поддержанием связи между хостами, пользуются самыми разными сетевыми устройствами, в число которых также входят хабы, маршрутизаторы, свичи, а также сетевые адаптеры хостов. Любой из перечисленных имеет сетевые интерфейсы. Любой сетевой интерфейс способен передавать и принимать трафик с завершенной скоростью. Когда скорость, с которой трафик направлялся на интерфейс, превышает ту скорость, с которой интерфейс осуществляет передачу дальше трафика, то зачастую получается перегрузка.
Сетевые устройства способны обрабатывать состояние перегрузки, организовывая целую цепь трафика в памяти устройства (в его буфере), пока она (перегрузка) не пройдет. В иных же случаях оборудование может не принимать трафик, для того чтобы сделать перегрузку менее тяжелой. Как результат, приложения встречаются со значительным изменением времени ожидания (потому что трафик остается в очередях на интерфейсах) или даже с полной потерей трафика.
Возможности интерфейсов, касающиеся пересылки сетевого трафика и наличие памяти, предназначенной для хранения трафика в сетевых устройствах будут составлять фундаментальные ресурсы, которые в свою очередь требуются для обеспечения службы QoS для продолжения потоков трафика в приложениях.
Распределение ресурсов службы QoS по сетевым устройствам
Устройства, которые поддерживают рассматриваемую службу, относительно рационально пользуются ресурсами сети для передачи сетевого трафика. То бишь трафик приложений, которые соответственно более терпимы к задержкам, хранится в буфере, а трафик приложений, который в определенной степени более критичен к задержкам, отсылается дальше.
Для того, чтобы решить эту проблему сетевое устройство должно прежде всего осуществлять идентификацию трафика путем распределения пакетов, а также составлять очереди и осуществлять посредством собственных механизмов, их обслуживание
Механизмы и способы обработки трафика
Подавляющее большинство локальных сетей основывается на технологии iEEE 802 и включает token —ring , Ethernet и так далее. 802.1p является механизмом обработки трафика для поддержки службы QoS в подобного рода сетях.
802.1p способно определить поле (второй уровень в сетевой модели OSI ) в заглавии пакета 802, которое несет какое-то значение приоритета. Обычно, маршрутизаторы или же хосты, отсылая свой трафик в локальную сеть, маркируют все посланные ими пакеты, присваивая им какое-то значение приоритета. Подразумевается, что свичи, хабы, мосты и иные сетевые устройства будут обрабатывать пакеты путем организации очередей. Область применения указанного механизма обработки трафика ограничивается LAN . В тот же момент, когда пакет пересекает LAN (через третий уровень OSI ), приоритет 802.1p сразу же удаляется
Механизм третьего уровня – Diffserv , который определяет в поле в третьем уровне загаловка IP -пакетов, которые называются DSCP (расш. Diffserv codepoint )
Itserv представляет из себя законченный пакет услуг, который определяет гарантированных сервис и сервис, который управляет перегрузками. Гарантированный сервис способен нести какой-то объем трафика с ограниченной задержкой. Сервис, который управляет загрузкой,вызывается нести какой-то объем трафика когда «появляется легкая загруженность сетей». Они являются в какой-то степени измеримыми услугами, так как они определяются, для того чтобы обеспечить соотношение QoS к какому-то количеству трафика.
Так как технология ATM может фрагментировать пакеты в сравнительно небольшие ячейки, то оно способно предложить весьма заниженное время задержки. Если нужно передать пакет срочно, то интерфейс ATM может всегда освободиться для передачи на время, которое нужно, чтобы передать лишь одну ячейку.
Также служба QoS имеет в своём распоряжении довольно много непростых механизмов, которые обеспечивают работу такой технологии. Хотим отметить только лишь один, но очень существенный момент: для того, чтобы служба начала функционировать, нужна поддержка такой технологии и наличие необходимой настройки на всех передачах от первоначального пункта и до конечного
Нужно принять:
Абсолютно все маршрутизаторы принимают участиев передаче необходимых протоколов;
Первый QoS —сеанс, котор ый требует 64 кбпс, инициализируется между хостами A и B
Второй сеанс, который требует 64 кбпс, инициализируется между хостами A и D
Для того, чтобы значительно упростить схему предпологаем, что конфигурация маршрутизаторов конструируется таким образом, чтоони имеют возможность резервировать абсолютно все сетевые ресурсы.
Для нас важно, что один вопрос о резервировании 64 кбпс должен был достигнуть трех маршрутизаторов по пути потока информации между хостами A и B . Следующий запрос о 64 кбпс смог бы д остигнуть трех маршуртизаторов между хостами A и D . Маршрутизаторы бы смогли исполнить запросы на резервировании ресурсов, так как они не больше максимально указанной точки. Если же вместо этого любой из хостов B и C смог бы инициализировать 64 кбпс QoS -сеанс с А-хостом, то в таком случае маршрутизатор, который обслуживает указанные хосты, скорее всего запретил бы какое-то одно соединение.
А сейчас попробуем представить, что сетевой администратор выключает обработку службы в трех маршрутизаторах, которые обслуживают хост E ,D ,C ,B . В таком случае запросы о ресурсах больших 64 кбпс будут удовлетворяться вне зависимости от расположения хоста, который принимает участие в создании. В этом случае гарантии качества были бы крайне низки, так как трафик для единого хоста наносил бы ущерб трафику другого. Качество обслуживания, скорее всего, могло бы остаться прежним, если бы верхний маршрутизатор смог ограничить запросы до 64кбпс, но это бы привело к крайне неэффективному использованию ресурсов сети.
С другой же стороны, пропускную способность всех связей в сети мы могли бы увеличить до 128 кбпс. Однако увеличенная пропускная способность будет использоваться только лишь если два хоста будут одновременно требовать ресурсы. Если это не будет так, то сетевые ресурсы вновь станут использоваться крайне неэффективно
Майкрософтовские QoS -компонент ы
98 версия Windows располагает лишь компонентами QoS только для уровня пользователей:
QoS сервис провайдер
Winsock 2 (GQoS API )
Некоторые компоненты приложений
Более поздние операционные системы компании Майкрософт содержат все, что указано выше, а также такие компоненты, как:
Traffic .dll – возможность управления трафиком
Rsvpsp .dll и служб ы rsvp .exe ,а также QoS ACS . В XP и 2003 не используются
Mspgps .sys – классификатор пакетов, способен определить класс сервиса, принадлежащий пакету.
Psched .sys является планировщиком пакетов службы QoS . Его функция заключается в определении параметров службы для специфического потока информации. Весь трафик будет отмечаться каким-то значением приоритета. Планировщик пакетов будет определять трафик, путем постановки в очередь всех покетов и обрабатывать конкурирующие запросы через поставленные в очередь пакеты данных, которые нуждаются в своевременном доступе к сети.
Планировщик пакетов QoS (Psched.sys). Определяет параметры QoS для специфического потока данных. Трафик помечается определенным значением приоритета. Планировщик пакетов QoS определяет график постановки в очередь каждого пакета и обрабатывает конкурирующие запросы между поставленными в очередь пакетами, которые нуждаются в одновременном доступе к сети.
Финальный аккорд
Все вышеизложенные моменты не могут дать одного ответа на вопрос, куда же все-таки уходят те самые 20 процентов (которые, к слову сказать, никто еще точно не измерил). Исходя из всей информации, которая указана выше, этого быть ни в коем случае не должно. Однако оппоненты выдвигают свой довод: система QoS отличная, да вот реализована неважно. И, как следствие, 20% все же уходят. Скорее всего, проблема допекла и самого гиганта софта, так как он уже очень давно в свою очередь стал опровергать подобного плата мысли.
Нет ни одного человека, который бы хоть раз не прочитал какой-нибудь FAQ по Windows XP. А раз так, то каждый знает, что есть такая вредная служба Quality of Service - сокращенно QoS. При настройке системы ее настоятельно рекомендуется отключать, потому что она по умолчанию ограничивает сетевую пропускную способность на 20%, и как будто бы эта проблема существует и в Windows 2000.
Вот эти строки:
"Q: Как полностью отключить службу QoS (Quality of Service)? Как ее настроить? Правда ли, что она ограничивает скорость сети?
A: Действительно, по умолчанию Quality of Service резервирует для своих нужд 20% от пропускной способности канала (любого - хоть модем на 14400, хоть гигабитный Ethernet). Причем даже если удалить службу QoS Packet Scheduler из Properties-соединения, этот канал не освобождается. Освободить канал или просто настроить QoS можно здесь. Запускаем апплет Group Policy (gpedit.msc). В Group Policy находим Local computer policy и нажимаем на Administrative templates. Выбираем пункт Network - QoS Packet Sheduler. Включаем Limit reservable bandwidth. Теперь снижаем Bandwidth limit 20% до 0% или просто отключаем его. При желании здесь же можно настроить и другие параметры QoS. Для активации произведенных изменений остается только перезагрузиться".
20% - это, конечно, очень много. Воистину Microsoft - "маздай". Утверждения подобного рода кочуют из FAQ в FAQ, из форума в форум, из СМИ в СМИ, используются во всевозможного рода "твикалках" - программах по "настройке" Windows XP (кстати говоря, откройте "Групповые политики" и "Локальные политики безопасности", и ни одна "твикалка" не сравнится с ними по богатству вариантов настройки). Разоблачать голословные утверждения такого рода нужно осторожно, что мы сейчас и сделаем, применив системный подход. То есть основательно изучим проблемный вопрос, опираясь на официальные первоисточники.
Что такое сеть с качественным сервисом?
Давайте примем следующее упрощенное определение сетевой системы. Приложения запускаются и работают на хостах и обмениваются данными между собой. Приложения отправляют данные операционной системе для передачи по сети. Как только данные переданы операционной системе, они становятся сетевым трафиком.
Сетевая служба QoS опирается на способность сети обработать этот трафик так, чтобы гарантированно выполнить запросы некоторых приложений. Это требует наличия фундаментального механизма по обработке сетевого трафика, способного идентифицировать трафик, имеющий право на особую обработку и право управлять этими механизмами.
Функциональные возможности QoS призваны удовлетворить двух субъектов сети: сетевые приложения и сетевых администраторов. Они часто имеют разногласия. Администратор сети ограничивает ресурсы, используемые специфическим приложением, в то же время приложение пытается захватить как можно больше сетевых ресурсов. Их интересы могут быть согласованы, принимая во внимание тот факт, что сетевой администратор играет главенствующую роль по отношению ко всем приложениям и пользователям.
Основные параметры QoS
Различные приложения имеют различные требования по обработке их сетевого трафика. Приложения в большей или меньшей степени терпимы к задержкам и потерям трафика. Эти требования нашли применение в следующих параметрах, связанных с QoS:
Если бы были доступны бесконечные сетевые ресурсы, то весь трафик приложения можно было бы передать с требуемой скоростью, с нулевым временем задержки, нулевым изменением времени задержки и нулевыми потерями. Однако сетевые ресурсы не безграничны.
Механизм QoS контролирует распределение сетевых ресурсов для трафика приложения, чтобы выполнить требования по его передаче.
Фундаментальные ресурсы QoS и механизмы обработки трафика
Сети, которые связывают хосты, используют разнообразные сетевые устройства включая сетевые адаптеры хостов, маршрутизаторы, свичи и хабы. Каждый из них имеет сетевые интерфейсы. Каждый сетевой интерфейс может принять и передать трафик с конечной скоростью. Если скорость, с которой трафик направлен на интерфейс, выше, чем скорость, с которой интерфейс передает трафик дальше, то возникает перегрузка.
Сетевые устройства могут обработать состояние перегрузки, организуя очередь трафика в памяти устройства (в буфере), пока перегрузка не пройдет. В других случаях сетевое оборудование может отказаться от трафика, чтобы облегчить перегрузку. В результате приложения сталкиваются с изменением времени ожидания (так как трафик сохраняется в очередях на интерфейсах) или с потерей трафика.
Способность сетевых интерфейсов к пересылке трафика и наличие памяти для сохранения трафика в сетевых устройствах (до тех пор, пока трафик не может быть послан дальше) составляют фундаментальные ресурсы, требующиеся для обеспечения QoS для потоков трафика приложений.
Распределение ресурсов QoS по сетевым устройствам
Устройства, поддерживающие QoS, разумно используют ресурсы сети для передачи трафика. То есть трафик приложений, более терпимых к задержкам, становится в очередь (сохраняется в буфере в памяти), а трафик приложений, критичных к задержкам, передается далее.
Для выполнения этой задачи сетевое устройство должно идентифицировать трафик путем классификации пакетов, а также иметь очереди и механизмы их обслуживания.
Механизм обработки трафика
Механизм обработки трафика включает в себя:
Большинство локальных сетей основано на технологии IEEE 802 включая Ethernet, token-ring и др. 802.1p - это механизм обработки трафика для поддержки QoS в таких сетях.
802.1p определяет поле (уровень 2 в сетевой модели OSI) в заголовке пакета 802, которое может нести одно из восьми значений приоритета. Как правило, хосты или маршрутизаторы, посылая трафик в локальную сеть, маркируют каждый посланный пакет, присваивая ему определенное значение приоритета. Предполагается, что сетевые устройства, такие, как свичи, мосты и хабы, обработают пакеты соответствующим образом, используя механизмы организации очередей. Область применения 802.1p ограничена локальной сетью (LAN). Как только пакет пересекает локальную сеть (через уровень 3 OSI), приоритет 802.1p удаляется.
Diffserv - это механизм уровня 3. Он определяет поле в уровне 3 заголовка пакетов IP, названных diffserv codepoint (DSCP).
Intserv - это целый комплекс услуг, определяющий гарантированный сервис и сервис, управляющий загрузкой. Гарантированный сервис обещает нести некоторый объем трафика с измеримой и ограниченной задержкой. Сервис, управляющий загрузкой, соглашается нести некоторый объем трафика с "появлением легкой загруженности сети". Это - измеримые услуги в том смысле, что они определены, чтобы обеспечить измеримый QoS к определенному количеству трафика.
Поскольку технология ATM фрагментирует пакеты в относительно маленькие ячейки, то она может предложить очень низкое время задержки. Если необходимо передать пакет срочно, интерфейс ATM может всегда освобождаться для передачи на время, которое требуется, чтобы передать одну ячейку.
QoS имеет еще много разных сложных механизмов, обеспечивающих работу этой технологии. Отметим лишь один важный момент: для того, чтобы QoS заработала, необходима поддержка этой технологии и соответствующая настройка на всем протяжении передачи от начальной точки до конечной.
Для наглядности рассмотрим рис. 1.
Принимаем следующее:
В нашем случае один запрос о резервировании 64 Kbps достиг бы трех маршрутизаторов на пути данных между хостом А и хостом B. Другой запрос о 64 Kbps достиг бы трех маршрутизаторов между хостом А и хостом D. Маршрутизаторы выполнили бы эти запросы на резервирование ресурсов, потому что они не превышают максимума. Если вместо этого каждый из хостов B и C одновременно инициализировал бы 64 Kbps QoS-сеанс с хостом A, то маршрутизатор, обслуживающий эти хосты (B и C), запретил бы одно из соединений.
Теперь предположим, что администратор сети отключает обработку QoS в трех нижних маршрутизаторах, обслуживающих хосты B, C, D, E. В этом случае запросы о ресурсах до 128 Kbps удовлетворялись бы независимо от месторасположения участвующего в соединении хоста. При этом гарантии качества были бы низки, поскольку трафик для одного хоста подвергал бы риску трафик другого. Качество обслуживания могло бы быть сохранено, если бы верхний маршрутизатор ограничивал все запросы до 64 Kbps, однако это привело бы к неэффективному использованию сетевых ресурсов.
С другой стороны, пропускную способность всех сетевых связей можно было бы увеличить до 128 Kbps. Но увеличенная пропускная способность будет использоваться только когда хосты B и C (или D и E) одновременно затребуют ресурсы. Если это не так, то ресурсы сети опять будут использоваться неэффективно.
QoS-компоненты Microsoft
Windows 98 содержит компоненты QoS только пользовательского уровня включая:
Операционная система Windows 2000/XP/2003 содержит все описанное выше и следующие компоненты:
Диаграмма на рис.2 иллюстрирует стек протоколов, компоненты Windows и их взаимодействие на хосте. Элементы, использовавшиеся в Windows 2000, но не использующиеся в Windows XP/2003, на диаграмме не показаны.
Приложения находятся наверху стека. Они могут знать или не знать о QoS. Чтобы использовать всю мощь QoS, Microsoft рекомендует использовать в приложениях вызовы Generic QoS API. Это особенно важно для приложений, требующих высококачественных гарантий обслуживания. Некоторые утилиты могут использоваться для вызова QoS от имени приложений, которые не знают о QoS. Они работают через API управления трафиком. Например, NetMeeting использует GQoS API. Но для таких приложений качество не гарантируется.
Последний гвоздь
Вышеизложенные теоретические моменты не дают однозначного ответа на вопрос, куда деваются пресловутые 20% (которые, замечу, никто еще точно не измерял). Исходя из вышесказанного, такого быть не должно. Но оппоненты выдвигают новый довод: система QoS хорошая, да реализация кривая. Стало быть, 20% все-таки "отжираются". Видать, проблема допекла и софтверного гиганта, поскольку он уже довольно давно отдельно опроверг подобные измышления.
Впрочем, дадим слово разработчикам и изложим избранные моменты из статьи "316666 - Windows XP Quality of Service (QoS) Enhancements and Behavior" литературным русским языком:
"Сто процентов сетевой полосы пропускания доступны для распределения между всеми программами, если какая-либо программа явно не запрашивает приоритетную полосу пропускания. Эта "зарезервированная" полоса пропускания доступна другим программам, если программа, которая ее затребовала, не отправляет данные.
По умолчанию программы могут резервировать до 20% основной скорости соединения на каждом интерфейсе компьютера. Если программа, которая резервировала полосу пропускания, не посылает достаточно много данных, чтобы использовать ее полностью, неиспользованная часть зарезервированной полосы пропускания доступна для других потоков данных.
Были заявления в различных технических статьях и телеконференциях, что Windows XP всегда резервирует 20% доступной полосы пропускания для QoS. Эти заявления неверны".
Если теперь у кого-то все еще "отжирается" 20% полосы пропускания, что ж, я могу посоветовать и дальше использовать побольше всевозможных "твикалок" и кривых сетевых драйверов. Еще и не столько будет "отжираться".
Все, миф о QoS, умри!
о телефонии мы обсудили общие причины проблем со связью. Но довольно часто они возникают, потому что не хватает пропускной способности роутера. Если один человек звонит, а пять его коллег одновременно слушают музыку, то возможны перебои. В этой статье мы разберем настройки, которые позволят дать “зеленый свет” в первую очередь данным IP-телефонии.Телефонная связь через интернет возможна благодаря SIP-протоколу, который решает вопросы взаимодействия мультимедийных протоколов (видео/аудио). Более подробно этот процесс описан в статье . Когда один из собеседников говорит, звук его голоса кодируется и разбивается на пакеты, которые в течение разговора передаются другому устройству.
Но никто не использует интернет только ради IP-телефонии, поэтому через один канал передаются различные виды данных. Для роутера все они условно одинаковы, и такое “равноправие” иногда приводит к проблемам со связью.
Приведем упрощенный пример. Отец смотрит онлайн-трансляцию матча, сын слушает музыку в соцсети, а мать в это время хочет позвонить бабушке по скайпу. Но звук начинает прерываться, потому что аудио- и видео-трафик, который потребляют другие домочадцы, почти целиком “забил” канал. И пакеты с аудиоданными ожидают очереди на обработку, что приводит к проблемам со связью.
В большинстве случаев телефонный разговор гораздо важнее развлекательного ролика на Youtube или задержки в отправке письма, которая займет доли секунды. Но такая же задержка в случае со звуком ощутимо отразится на качестве связи. Поэтому желательно настраивать так называемую приоретизацию трафика , которая позволит пропускать данные IP-телефонии в первую очередь.
Quality of Service (QoS) - это технология предоставления различным классам данных различных приоритетов в обслуживании. QoS является встроенной функцией некоторых моделей роутеров.
Если настроить приоретизацию для данных IP-телефонии, то устройство будет определять их среди проходящего трафика и предоставлять им максимальный приоритет, что может значительно повысить качество связи. На картинке ниже наглядно показана разница в работе устройства с QoS и без него.
Источник изображения VAS Experts
Перед тем, как настроить QoS, нужно учесть два момента. Во-первых, приоретизация оправдана, только если канал сильно загружен и возникает очередь на обслуживание пакетов. Если вам нужно лишь изредка звонить знакомым, то настройка QoS - лишняя трата времени. Но для компании, которая использует связь от оператора IP-телефонии, без этой технологии не обойтись. Аналогично, если вы используете коллтрекинг от Ringostat , поэтому ниже мы подготовили рекомендации по настройке.
Во-вторых, QoS - это не волшебная пилюля. Если канал слишком узкий, то приоретизация трафика все равно не поможет. Физический буфер устройства, куда помещаются все готовые к выходу пакеты, будет переполняться. И тогда вновь поступающие пакеты будут уничтожаться - даже если они важны для пользователя.
Поэтому обращайте внимание на характеристики роутера и максимальный размер очереди обработки пакетов. Например, на маршрутизаторах Cisco он составляет примерно 128–256 пакетов. Допустимо, если эта очередь превышает до 20% от его пропускной способности. Но если больше - то это повод заняться дизайном сети и прокладкой дополнительных маршрутов.
Чтобы избежать заторов в канале, мы должны “пометить” VoIP-данные и дать понять роутеру, что они важны для нас в первую очередь. Существует два варианта приоретизации трафика.
1. Выставление приоритета в веб-интерфейсе роутера
Не существует универсального способа настройки QoS для роутеров. Все зависит от конкретного устройства. Вот, например, как этот процесс описан в инструкции по настройке QoS для роутера TP-Link . В основном, приоритет назначается по протоколу - в случае с телефонией нам в первую очередь важен SIP/ RTP. RTP (Real-time Transport Protocol) - протокол, используемый для передачи звука.
Также приоретизацию можно настраивать по портам. В этом случае устройство будет понимать, что все данные, поступающие с конкретного порта, нужно пропускать в первую очередь. Так, при использовании программы для связи (диалера) VoIP-трафик будет поступать с порта 5060. Также доступна приоретизация по типу трафика. Выбор вида приоретизации зависит от количества трафика, его типа и настроек приложений, которые используются для связи и т. д.
2. Выставление приоритета в приложении для связи
Если говорить обобщенно, то в заголовках различных сетевых протоколов (Ethernet, IP, ATM, MPLS и др.) присутствуют специальные поля, выделенные для маркировки трафика. Вписывая туда нужные значения, вы отмечаете определенные данные как особенно важные. И роутер будет пропускать их в первую очередь.
В этом случае QoS настраивается не в устройстве для интернет-соединения, а в программе, с помощью которой вы звоните. Для этого нужно зайти в ее сетевые настройки и прописать нужные значения для пакетов с аудиоданными. Вот например, как это описано в инструкции для Zoiper .
Остановимся на этом способе подробней, потому что он позволяет быстрее обрабатывать информацию. В этом случае уже по самому IP-заголовку пакета роутер понимает, что это приоритетные данные, и пропускает их быстрее. А в первом случае ему дополнительно приходится “раскрывать” пакет, чтобы распознать, какое содержимое внутри. Кроме того, маркировать данные лучше всего ближе к их источнику. В нашем случае этим источником является программа для связи.
В качестве примера разберем настройку приоритетизации в приложении Zoiper. Для этого нужно найти в папке программы для связи конфигурационный файл. Например, для Zoiper это «Config.xml». С помощью редактора, совместимого с XML, найдите нужные строки и впишите в них значение EF, CS или AF . Выбор нужного значения зависит от возможностей роутера - более подробно свойства значений описаны в статье на Википедии , которая включает в себя список стандартов.
В настройках нужно указать значения для параметров:
EF
EF
Вот как выглядит содержимое пакета после настройки QoS в программе Zoiper. На скриншоте видны: протокол, его заголовок и значение, которое мы ввели. EF означает Expedited forwarding (англ. “ускоренная пересылка”) - т. е. в данном случае наивысший приоритет:
Единственный минус этого способа - хоть большинство роутеров и могут понимать приоритет по заголовку, но не все. Детали настройки зависят от устройства и сервиса, которые вы используете. Но инструкцию несложно найти, достаточно загуглить “как настроить QoS для N”.
Качество связи играет большую роль для бизнеса. У нас есть не один кейс о том, как настройка телефонии принесла увеличение количества заявок. Мы понимаем, что тема это непростая, поэтому не стесняйтесь - задавайте вопросы в комментариях. Если напишете в чат, расположенный справа, служба техподдержки ответит в течение пяти минут.
Начнем с определений:
Сравнение IPP и DSCP.
Попробуем разобраться, что такое 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 – потеря (отбрасывание) пакетов при передачи данных.
Существуют 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) включает функции распределения ресурсов и отбрасывания пакетов.
Начнем с определений:
Классификация пакетов (Packet Classification) - отнесение пакета к определенному классу.
Маркировка пакетов (Packet Marking) - установка требуемого приоритета.
Следует отметить, что классификация и маркировка пакетов отличаются в зависимости от уровня OSI, на котором работает устройство. Как правило, все коммутаторы работают на уровне L2, а именно с Ethernet кадрами. Маршутизаторы работают на уровне L3 и уже не с кадрами, а пакетами.
В протоколе 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.
На 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.
Разберем более подробно понятие PHB.
Per-Hop Behaviors (PHB) - это политика пошагового обслуживания, иными словами, это некий алгоритм действий по обработки пакетов, выполняемый на каждом узле. PHB определяет, к какой из очередей отнести пакет, а также сброс пакетов в очереди в случае перегрузок.
Существуют 4 стандартизованных PHB.
Применяется для передачи Best-Efforts (негарантированая доставка) трафика, т.е. нет никакой маркировки, а точнее биты DSCP с 5 по 7 равны 000. Используется для совместимости с сетевыми устройствами, не поддерживающими маркировку или если она не используется.
Распределение бит DSCP в Default PHB.
Используется для передачи трафика, чувствительного к задержкам. Биты DSCP с 5 по 7 равны 101. Пакеты, помеченные как EF, передаются с наименьшей задержкой в очереди.
Распределение бит DSCP в EF PHB.
Используется для гарантированной доставки. Значение бит DSCP с 5 по 7 может принимать 4 значения (001, 010, 011, 100), следовательно получается четыре стандартных класса AF (AF1, AF2, AF3, AF4), а внутри каждого класса может существует три уровня сбросса пакетов (low, medium, high).
Распределение бит DSCP в AF PHB.
aaa - номер класс обслуживания.
dd - вероятность сброса пакета.
Значение бит 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 - тема большая. Прежде чем рассказывать про тонкости настроек и различные подходы в применении правил обработки трафика, имеет смысл напомнить, что такое вообще 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 group
any
Any packets
class-map
Class map
cos
IEEE 802.1Q/ISL class of service/user priority values
destination-address
Destination address
discard-class
Discard behavior identifier
dscp
Match DSCP in IP(v4) and IPv6 packets
flow
Flow based QoS parameters
fr-de
Match on Frame-relay DE bit
fr-dlci
Match on fr-dlci
input-interface
Select an input interface to match
ip
IP specific values
mpls
Multi Protocol Label Switching specific values
not
Negate this match result
packet
Layer 3 Packet length
precedence
Match Precedence in IP(v4) and IPv6 packets
protocol
Protocol
qos-group
Qos-group
source-address
Source address
vlan
VLANs to match
Пакеты в классы можно рассортировывать по различным атрибутам, например, указывая ACL, как шаблон, либо по полю DSCP, либо выделяя конкретный протокол (включается технология NBAR)
Создание политики:
policy-map POLICY
class NAME1
?
bandwidth
Bandwidth
compression
Activate Compression
drop
Drop all packets
log
Log IPv4 and ARP packets
netflow-sampler
NetFlow action
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
Для каждого класса в политике можно либо выделить приритетно кусок полосы:
policy-map POLICY
class NAME1
priority?
Kilo Bits per second
percent
% of total bandwidth
и тогда пакеты этого класса смогут всегда рассчитывать как минимум на этот кусок.
Либо описать, какой «вес» имеет данный класс в рамках CBWFQ
policy-map POLICY
class NAME1
bandwidth?
Kilo Bits per second
percent
% of total Bandwidth
remaining
% of the remaining bandwidth
В обоих случаях можно указать как аболютное значение, так и процент от всей доступной полосы
Возникает резонный вопрос: а откуда маршрутизатор знает ВСЮ полосу? Ответ банален: из параметра bandwidth на интерфейсе. Даже если он не сконфигурирован явно, какое то его значение обязательно есть. Его можно посмотреть командой sh int.
Также обязательно помнить, что по умолчанию вы распоряжаетсь не всей полосой, а лишь 75%. Пакеты, явно не попавшие в другие классы, попадают в class-default. Эту настройку для дефолтного класса можно задать явно
policy-map POLICY
class class-default
bandwidth percent 10
max-reserved-bandwidth
Маршрутизаторы ревностно следят, чтобы админ не выдал случайно больше полосы, чем есть и ругаются на такие попытки.
Создаётся впечатление, что политика будет выдавать классам не больше, чем написано. Однако, такая ситуация будет лишь в том случае, если все очереди наполнены. Если же какая то пустует, то выделенную ей полосу наполненные очереди поделят пропорционально своему «весу».
Работать же вся эта конструкция будет так:
Если идут пакеты из класса с указанием priority, то маршрутизатор сосредотачивается на передаче этих пакетов. Причем, т.к. таких приоритетных очередей может быть несколько, то между ними полоса делится пропорционально указанным процентам.
Как только все приоритетные пакеты закончились, наступает очередь CBWFQ. За каждый отсчёт времени из каждой очереди «зачёрпывается» доля пакетов, указанная в настройке для данного класса. Если же часть очередей пустует, то их полоса делится пропорционально «весу» класса между загруженными очередями.
Применение на интерфейсе:
int s0/0
service-policy POLICY
А что же делать, если надо строго рубить пакеты из класса, выходящие за дозволенную скорость? Ведь указание bandwidth лишь распределяет полосу между классами, когда очереди загружены.
Для решения этой задачи для класса трафика в политике есть технология
police conform-action [действие] exceed-action [действие]
Она позволяет явно указать желаемую среднюю скорость (speed), максимальный «выброс», т.е. количество передаваемых данных за единицу времени. Чем больше «выброс», тем больше реальная скорость передачи может отклоняться от желаемой средней. Также указываются: действие для нормального трафика, не превышающего
указанную скорость и действие для трафика, превысившего среднюю скорость. Действия могут быть такими
police 100000 8000 conform-action?
drop
drop packet
exceed-action
action when rate is within conform and
conform + exceed burst
set-clp-transmit
set atm clp and send it
set-discard-class-transmit
set discard-class and send it
set-dscp-transmit
set dscp and send it
set-frde-transmit
set FR DE and send it
set-mpls-exp-imposition-transmit
set exp at tag imposition and send it
set-mpls-exp-topmost-transmit
set exp on topmost label and send it
set-prec-transmit
rewrite packet precedence and send it
set-qos-transmit
set qos-group and send it
transmit
transmit packet
Часто возникает также и другая задача. Предположим, что надо ограничить поток, идущий в сторону соседа с медленным каналом.
Дабы точно предсказать, какие пакеты дойдут до соседа, а какие будут уничтожены в силу загруженности канала на «медленной» стороне, надо на «быстрой» стороне создать политику, которая бы заранее обрабатывала очереди и уничтожала избыточные пакеты.
И тут мы сталкиваемся с одной очень важной вещью: для решения этой задачи надо сэмулировать «медленный» канал. Для этой эмуляции не достаточно только раскидать пакеты по очередям, надо ещё сэмулировать физический буфер «медленного» интерфейса. У каждого интерфейса есть скорость передачи пакетов. Т.е. в единицу времени каждый интерфейс может передать не более, чем N пакетов. Обычно физический буфер интерфейса рассчитывают так, чтобы обеспечить «автономную» работу интерфейсу на несколько единиц вермени. Поэтому физический буфер, скажем, GigabitEthernet будет в десятки раз больше какого-нибудь интерфейса Serial.
Что же плохого в том, чтобы запомнить много? Давайте рассмотрим подробно, что произойдёт, в случае если буфер на быстрой передающей стороне будет существенно больше буфера принимающей.
Пусть для простоты есть 1 очередь. На «быстрой» стороне сэмулируем малую скорость передачи. Это значит, что попадая под нашу политику пакеты начнут накапливаться в очереди. Т.к. физический буфер большой, то и логическая очередь получится внушительной. Часть приложений (работающих через ТСР) поздно получат уведомление о том, что часть пакетов не получена и долго будут держать большой размер окна, нагружая сторону-приемник. Это будет происходить в том идеальном случае, когда скорость передачи будет равна или меньше скорости приёма. Но интерфейс принимающей стороны может быть сам загружен и другими пакетами
и тогда маленькая очередь на принимающей стороне не сможет вместить всех пакетов, передаваемых ей из центра. Начнутся потери, которые повлекут за собой дополнительные передачи, но в передающем буфере ведь ещё останется солидный «хвост» ранее накопленных пакетов, которые будут передаваться «вхолостую», т.к. на принимающей стороне не дождались более раннего пакета, а значит более позние будут просто проигнорированы.
Поэтому для корректного решения задачи понижения скорости передачи к медленному соседу физический буфер тоже надо ограничить.
Делается это командой
shape average
Ну а теперь самое интересное: а как быть, если мне помимо эмуляции физического буфера надо внутри него создать логические очереди? Например, выделить приоритетно голос?
Для это создаётся так называемая вложенная политика, которая применяется внутри основной и делит на логические очереди то, что в неё попадает из родительской.
Пришло время разобрать какой-нибудь залихватский пример на основе приведенной картинки.
Пусть мы собираеися создать устойчиво работающие голосовые каналы через интернет между 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 не доступны.
Причем часто червь распространяется по нужным для работы портам (ТСР/135,445,80 и др.) Просто закрыть на маршрутизаторе эти порты было бы опрометчиво, поэтому гуманнее поступать так:
1. Собираем статистику по сетевому трафику. Либо по NetFlow, либо NBARом, либо по SNMP.
2. Выявляем профиль нормального трафика, т.е. по статистике, в среднем, протокол HTTP занимает не больше 70%, ICMP - не больше 5% и т.д. Такой профиль можно либо создать вручную, либо применив накопленную NBARом статистику. Мало того, можно даже автоматически создать классы, политику и применить на интерфейсе
командой autoqos
:)
3. Далее, можно ограничить для нетипичного сетевого трафика полосу. Если вдруг и подцепим заразу по нестандартному порту, большой беды для шлюза не будет: на загруженном интерфейсе зараза займет не более выделенной части.
4. Создав конструкцию (class-map - policy-map - service-policy ) можно оперативно реагировать на появление нетипичного всплеска трафика, создавая вручную для него класс и сильно ограничивая полосу для этого класса.
