Нас Защищает Роутер: Qos

QoS — это большая тема.

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

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

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

Именно там, в очереди, можно «проскользнуть» первым, воспользовавшись своим правом.

Очередь образуется там, где узко (обычно такие места называют «горлышком», бутылочным горлышком).

Типичным узким местом является офисное подключение к Интернету, где компьютеры, подключенные к сети со скоростью не менее 100 Мбит/сек, все используют канал до провайдера, скорость которого редко превышает 100 Мбит/сек, а зачастую составляет скудные 1-2 Мбит/сек.

-10 Мбит/сек.

Для всех.

Во-вторых, QoS — не панацея: если «шея» слишком узкая, то часто переполняется физический буфер интерфейса, куда помещаются все пакеты, которые собираются выйти через этот интерфейс.

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

Поэтому, если очередь на интерфейсе в среднем превышает 20% от его максимального размера (на маршрутизаторах Cisco максимальный размер очереди обычно составляет 128-256 пакетов), есть повод хорошенько задуматься над дизайном своей сети, проложить дополнительные маршруты или расширить пропускную способность до провайдера.

Разберемся в составляющих технологии (далее под катом, там много) Маркировка.

В полях заголовков различных сетевых протоколов (Ethernet, IP, ATM, MPLS и др.

) выделены специальные поля для маркировки трафика.

Трафик необходимо помечать для последующей более простой обработки в очередях.

Ethernet. Поле класса обслуживания (CoS) — 3 бита.

Позволяет разделить трафик на 8 потоков с разной маркировкой ИП.

Есть 2 стандарта: старый и новый.

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

Лучше всего маркировать данные рядом с источником данных.

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

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

Например, этим грешат одноранговые сети.

Очереди.

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

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

Если вы хотите дать какому-то выделенному классу абсолютный приоритет (т.е.

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

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

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

На маршрутизаторах Cisco вы можете создать 4 очереди с разными приоритетами.

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

Честная очередь( Честная очередь ).

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

Как правило, ею не пользуются, т.к.

мало что дает в плане повышения качества обслуживания.

Взвешенная справедливая очередь ( Взвешенная справедливая организация очередей, WFQ ).

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

«На первый взгляд» это выглядит так: все пакеты разбиваются на логические очереди с помощью Поле «Приоритет IP» в качестве критерия.

В этом же поле задается и приоритет (чем больше, тем лучше).

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

Нас защищает роутер: QoS

Он рассчитывает это по формуле: dT=(t(i)-t(0))/(1+IPP) IPP — значение поля приоритета IP-адресов t(i) — Время, необходимое для фактической передачи пакета интерфейсом.

Может быть рассчитано как L/Speed, где L — длина пакета, а Speed — скорость передачи интерфейса.

Эта очередь включена по умолчанию на всех интерфейсах маршрутизаторов Cisco, кроме интерфейсов «точка-точка» (инкапсуляция HDLC или PPP).

WFQ имеет ряд недостатков: такая организация очередей использует заранее размеченные пакеты и не позволяет самостоятельно определять классы трафика и выделенную полосу пропускания.

Более того, полем IP Precedence, как правило, уже никто не помечается, поэтому пакеты идут немаркированными, т.е.

все попадают в одну очередь.

Эволюцией WFQ стала взвешенная справедливая организация очередей на основе классов ( Взвешенная справедливая организация очередей на основе классов, CBWFQ ).

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

NBAR).

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

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

В этой технологии можно настроить до 4 приоритетных очередей, остальные классы обслуживаются с помощью механизма CBWFQ. LLQ — наиболее удобный, гибкий и часто используемый механизм.

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

Подробнее о настройках расскажу позже.

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

Ближе к источникам.

Обработка пакетов .

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

Технология QoS достаточно ресурсоемка и достаточно существенно нагружает процессор.

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

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

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

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

Создание классов: карта классов ИМЯ соответствовать? группа доступа Группа доступа любой Любые пакеты карта классов Карта классов потому что Класс обслуживания IEEE 802.1Q/ISL/значения приоритета пользователя адрес назначения Адрес назначения класс сброса Отменить идентификатор поведения dscp Сопоставление DSCP в пакетах IP(v4) и IPv6. поток Параметры QoS на основе потока фр-де Соответствие биту DE Frame Relay фр-dlci Матч на fr-dlci интерфейс ввода Выберите входной интерфейс для соответствия IP Особые значения IP МПЛС Конкретные значения мультипротокольного переключения меток нет Отменить результат этого совпадения пакет Уровень 3 Длина пакета приоритет Соответствие приоритета в пакетах IP(v4) и IPv6 протокол Протокол qos-группа Кос-группа адрес источника Адрес источника виртуальная локальная сеть Соответствующие VLAN Пакеты по классам можно сортировать по различным атрибутам, например, указав ACL в качестве шаблона, или по полю DSCP, или выделив конкретный протокол (технология NBAR включена) Создайте политику: политика-карта ПОЛИТИКА класс NAME1 ? пропускная способность Пропускная способность сжатие Активировать сжатие уронить Отбросить все пакеты бревно Регистрировать пакеты IPv4 и ARP netflow-сэмплер Действие NetFlow полиция Полиция приоритет Строгий приоритет планирования для этого класса лимит очереди Максимальный порог очереди для отбрасывания хвоста случайное обнаружение Включить случайное раннее обнаружение в качестве политики удаления политика обслуживания Настроить поток далее набор Установите значения качества обслуживания форма Формирование трафика Для каждого класса в политике вы можете выделить приоритетную часть полосы: политика-карта ПОЛИТИКА класс NAME1 приоритет? [8-2000000] Килобит в секунду процент % от общей пропускной способности и тогда пакеты этого класса всегда смогут рассчитывать хотя бы на этот кусок.

Или опишите, какой «вес» имеет этот класс в рамках CBWFQ. политика-карта ПОЛИТИКА класс NAME1 пропускная способность? [8-2000000] Килобит в секунду процент % от общей пропускной способности оставшийся % оставшейся пропускной способности В обоих случаях можно указать как абсолютное значение, так и процент от всей доступной полосы.

Возникает резонный вопрос: откуда роутер знает ВСЮ полосу? Ответ прост: из параметра пропускной способности интерфейса.

Даже если оно не настроено явно, оно должно иметь какое-то значение.

Посмотреть его можно с помощью команды sh int. Также необходимо помнить, что по умолчанию вы контролируете не весь страйп, а только 75%.

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

?Этот параметр для класса по умолчанию можно задать явно.

политика-карта ПОЛИТИКА класс класс по умолчанию пропускная способность процентов 10 (UPD, спасибо ОлегД) Изменить максимально доступную пропускную способность с 75% по умолчанию можно командой на интерфейсе максимальная зарезервированная пропускная способность [процент] Роутеры ревниво следят за тем, чтобы администратор случайно не выдал пропускную способность больше, чем есть, и ругаются на такие попытки.

Похоже, что политика выдаст классам не больше, чем написано.

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

Если один пуст, то выделенная ему полоса будет разделена заполненными очередями пропорционально ее «весу».

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

Причем, т.к.

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

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

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

Приложение интерфейса: интервал s0/0 политика-сервиса [вход|выход] ПОЛИТИКА Но что делать, если вам нужно жестко отрезать пакеты из класса, превышающие разрешенную скорость? В конце концов, указание пропускной способности распределяет пропускную способность между классами только тогда, когда очереди заняты.

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

объем передаваемых данных в единицу времени.

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

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

Действия могут быть такими полиция 100000 8000 конформ-акция? уронить отбросить пакет превышение действия действие, когда скорость находится в пределах соответствия и соответствовать + превышать взрыв set-clp-передача установите atm clp и отправьте его установить-отменить-класс-передачу установите класс сброса и отправьте его set-dscp-transmit установите dscp и отправьте его set-frde-transmit установите FR DE и отправьте его set-mpls-exp-наложение-передача задайте эксп при наложении тега и отправьте его set-mpls-exp-topmost-transmit установите exp на самую верхнюю метку и отправьте ее установка-прец-передача переписать приоритет пакета и отправить его set-qos-transmit установите qos-группу и отправьте ее передавать передать пакет Часто возникает и другая проблема.

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

Нас защищает роутер: QoS

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

И здесь мы сталкиваемся с одной очень важной вещью: для решения этой проблемы нам необходимо эмулировать «медленный» канал.

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

Каждый интерфейс имеет свою скорость передачи пакетов.

Те.

Каждый интерфейс может передавать не более N пакетов в единицу времени.

Обычно буфер физического интерфейса предназначен для обеспечения «автономной» работы интерфейса в течение нескольких единиц времени.

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

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

Для простоты пусть будет 1 очередь.

На «быстрой» стороне мы имитируем низкую скорость передачи.

Это означает, что пакеты, попадающие под нашу политику, начнут накапливаться в очереди.

Т.

к.

физический буфер большой, то логическая очередь будет внушительной.

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

Это произойдет в идеальном случае, когда скорость передачи равна или меньше скорости приема.

Но интерфейс принимающей стороны сам может быть загружен другими пакетами.

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

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

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

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

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

Допустим, мы собираемся создать стабильные голосовые каналы через Интернет между CO и Remote. Для простоты пусть удаленная сеть (172.16.1.0/24) имеет связь только с CO (10.0.0.0/8).

Скорость интерфейса на Remote составляет 1 Мбит/с и 25% этой скорости отводится голосовому трафику.

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

В СО дополнительно создадим класс, описывающий трафик между офисами По СО: карта классов RTP соответствие протокола rtp карта политики RTP класс RTP приоритет процентов 25 расширенный список доступа IP CO_REMOTE разрешить IP 10.0.0.0 0.255.255.255 172.16.1.0 0.0.0.255 карта классов CO_REMOTE совпадение со списком доступа CO_REMOTE На Remote мы поступим иначе: даже если мы не сможем использовать NBAR из-за неработающего оборудования, то мы сможем лишь явно описать порты для RTP. ip-список доступа, расширенный RTP разрешить udp 172.16.1.0 0.0.0.255 диапазон 16384 32768 10.0.0.0 0.255.255.255 диапазон 16384 32768 RTP карты классов соответствие списка доступа RTP политика-карта QoS класс RTP приоритет процентов 25 Далее на CO нужно эмулировать медленный интерфейс, применить вложенную политику для определения приоритетов голосовых пакетов.

политика-карта QoS класс CO_REMOTE форма в среднем 1000000 политика обслуживания RTP и примените политику к интерфейсу интервал г0/0 выходное качество обслуживания политики обслуживания На удаленном компьютере установите параметр пропускной способности (в кбит/сек), соответствующий скорости интерфейса.

Напомню, именно от этого параметра будет считаться 25%.

И применить политику.

интервал s0/0 пропускная способность 1000 выходное качество обслуживания политики обслуживания Рассказ был бы не полным, если бы мы не рассмотрели возможности коммутаторов.

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

На более умных L2/3 переключается на маршрутизируемых интерфейсах (т.е.

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

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

Как известно, червь сам по себе весьма агрессивен на этапе распространения и создает много паразитного трафика, то есть, по сути, представляет собой атаку типа «отказ в обслуживании» (DoS).

Более того, червь часто распространяется через необходимые для работы порты (TCP/135,445,80 и т.п.

Просто закрывать эти порты на роутере было бы безрассудно, поэтому гуманнее поступить так: 1. Собрать статистику сетевого трафика.

Либо через NetFlow, либо NBAR, либо SNMP. 2. Выявляем профиль нормального трафика, т.е.

по статистике в среднем протокол HTTP занимает не более 70%, ICMP - не более 5% и т.д. Такой профиль можно создать как вручную, так и с помощью статистика, накопленная НБАР.

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

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

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

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

Сергей Федоров Теги: #cisco #cisco #router #protection #qos