Для начала – зачем вообще нужен QoS в локальной сети? Казалось бы:
- полосы вполне достаточно (хотя это может быть спорным утверждением),
- заявляется, что пропускной способности коммутирующей фабрики вполне достаточно, чтобы пропускать трафик на скорости канала.
На самом деле, даже если бы у нас был самый быстрый в мире коммутатор, никто не застрахован от следующих 2-х случаев:
- Несоответствие скоростей входящего и исходящего интерфейсов, когда трафик, например, с гигабита пытается пролезть в 100Мб-интерфейс
- Агрегация скорости – когда трафик из нескольких гигабитных интерфейсов пытается запихнуться в один исходящий интерфейс
В обоих случаях на исходящем интерфейсе переполняется буфер, возрастает задержка и джиттер, и в худшем случае происходит неконтролируемый сброс пакетов. Вывод – QoS в локальной сети нам нужен.
В этой статье мы поговорим про настройку QoS на коммутаторе 2950 Enchanced Image. Сразу предупреждая возможные вопросы типа “он уже давно end of sale, зачем про него говорить?», я все же расскажу о нем, потому что:
- На курсе по QoS на вопрос «признавайтесь, у кого есть 2950?» стабильно несколько человек поднимают руки
- Чтобы сформировать базу для следующей статьи
- Чтобы показать, что даже на таком маленьком железе можно кое-что сделать
Очередность на 2950
Итак, коммутатор 2950 EI не лыком шит – у него на исходящих портах 4 очереди, которые могут работать в режимах:
- Strict Priority – похоже на PQ на рутерах. Пока не освободится очередь номер 4 (самая приоритетная) до 3-й дело не дойдет, пока не освободится 3-я, до 2-й дело не дойдет, и т.д. Не слишком правильный алгоритм, страдающий монополизацией полосы пропускания приоритетными потоками. Здесь это дефолтный алгоритм.
- Weighted Round Robin – взвешенная карусельная обработка. Отсутствует монополизация полосы пропускания, все очереди получают доступ к полосе, в тех пропорциях, которые мы настроим.
- Weighted Round Robin + PQ — взвешенная карусель с одной приоритетной очередью. То же, что и предыдущий пункт, но 4-я очередь имеет абсолютный приоритет. Все, что в нее попадет, немедленно обслуживается, гарантируя минимальную задержку. Именно этот режим используется для обработки голосовых фреймов.
Как понять, какой режим очередности включен на 2950? Не давайте команду show interface, она вас обманет. Лучше напишите show wrr-queue bandwidth. Если в ответ коммутатор радостно сообщит, что
wrr-queue bandwidth is disabled
то мы имеем Strict Priority. Если выводит табличку вида
WRR Queue : 1 2 3 4
Bandwidth : 10 20 10 40
то это означает, что мы имеем взвешенную карусельную обработку, а числа в строке Bandwidth как раз означают весовые коэффициенты — в каких пропорциях делить полосу пропускания. Важно, какой коэффициент он покажет для 4-й очереди. Если ненулевой, тогда мы имеем все 4 очереди в карусели. Если нулевой, это означает, что 4-я очередь работает в режиме Strict Priority.
Как настроить карусельную обработку очередей на 2950? В глобальном конфиге (то есть для всех портов сразу) даем команду:
sw(config)#wrr-queue bandwidth 10 40 10 20
эти числа – весовые коэффициенты соответственно для 1-й, 2-й, 3-й и 4-й очередей. Причем это именно веса – их сумма не обязана быть 100%. Диапазон каждого — от 1 до 255. Играет роль отношение между этими коэффициентами. А процент занятия полосы очередью считается как
коэффициент / (сумму всех коэффициентов)
На 4-й позиции мы можем написать 0. Это будет означать, что 4-я очередь обрабатывается с абсолютным приоритетом по сравнению со всеми остальными очередями. Обычно туда направляют голосовой трафик, а трафик данных распределяют между 1-3 очередями.
Как определить, в какую очередь должен попасть тот или иной пакет? Назначение трафика на исходящие очереди происходит по исходящему значению CoS. Дефолтная табличка назначения CoS на очереди:
sw#sh wrr-queue cos-map
CoS Value : 0 1 2 3 4 5 6 7
Priority Queue: 1 1 2 2 3 3 4 4
То есть CoS 1, 2 идут в 1-ю очередь, 3, 4 – во вторую и т.д. Настроить это можно командами
sw(config)#wrr-queue cos-map 1 0 1 2
sw(config)#wrr-queue cos-map 2 3 4
sw(config)#wrr-queue cos-map 3 6 7
sw(config)#wrr-queue cos-map 4 5
Первое число в команде – номер очереди, потом перечисляются CoS, которые должны туда идти. Раз уж мы используем 4-ю очередь для голоса, а голос рекомендуется маркировать CoS 5, то так и настроили (4-я команда).
2950 и IP-телефоны Cisco
Теперь поговорим про возможности 2950 по классификации и маркировке трафика. Поскольку 2950 обычно является устройством уровня доступа, то вполне возможно, что к нему будут подключаться IP-телефоны Cisco по следующей схеме:
Как мы с вами знаем, для этого на порту коммутатора предусмотрена команда настройки голосового VLAN:
sw(config-if)#switchport voice vlan 110
Коммутатор будет пересылать этот номер VLAN на телефон по протоколу CDPv2, и таким образом телефон узнает, какой номер VLAN ставить в тег 802.1q для голосовых фреймов. При этом трафик голоса телефон будет маркировать на 3-м уровне DSCP EF (2-ичный код 101110 или 46 в десятичном виде), а на 2-м уровне – CoS 5.
Наша задача — отделить мух от котлет, то есть сделать так, чтобы сотрудник не маркировал свой потенциально мусорный трафик высокой маркировкой. Так вот, маркировку CoS этого трафика телефон по умолчанию сбросит на 0. Обратите внимание, что он не обнулит DSCP в пакетах от PC! Этим уже будет заниматься коммутатор уровня доступа. Поскольку после телефона значение CoS уже «правильное», на порту коммутатора можно просто настроить режим доверия маркировке CoS. А чтобы сотрудник не схитрил и не подключился в коммутатор напрямую, надеясь при этом пропускать трафик с высоким значением CoS, коммутатор это сразу распознает (используя тот же CDPv2), и переведет порт в недоверенный режим. Это поведение настраивается 2-мя командами:
sw(config-if)#mls qos trust cos
sw(config-if)#mls qos trust device cisco-phone
Сразу предупреждая вопросы типа «а что, если подключить хаб между коммутатором и телефоном», или «а что, если спуфить CDP», скажу, что разработчики решения не предполагали, что наглость сотрудника может зайти так далеко. Всеж-таки CDP – далеко не самый секьюрный метод проверки.
Если же обнулять маркировку сотрудника не нужно, есть возможность в помощью команды на 2950 проинструктировать телефон, что делать с CoS от PC. Возможны варианты:
- Сбрасывать не на 0, а на другое значение (1-7)
- Не трогать, то есть доверять
Достигается это командой:
sw(config-if)#switchport priority extend cos [0-7] <- менять
или
sw(config-if)#switchport priority extend cos trust <- доверять
Называется эта фича Extended Trust Boundary (расширенная граница доверия)
Круговорот маркировок в 2950
Какие еще варианты настроек поддерживает 2950, кроме подключения телефона?
- Безусловное доверие CoS (с перемаркировкой DSCP)
- Безусловное доверие CoS (с сохранением DSCP)
- Безусловное доверие DSCP
- Недоверенный режим
- Обработка не-IP трафика
Чтобы свичу не запутаться во всем это многообразии маркировок, любая маркировка приводится к некому «общему знаменателю» — Internal DSCP. Даже не-IP пакет внутри 2950 имеет значение Internal DSCP. Для преобразования есть специальные таблички – CoS-DSCP и DSCP-CoS, которые есть дефолтные, и их можно настраивать.
Итак, вариант 1- порт настроен в режим доверия CoS.
sw(config-if)#mls qos trust cos
Входящий CoS преобразуется в Internal DSCP по табличке CoS-DSCP, и записывается в заголовок пакета, меняя там DSCP, который был ранее. Далее по табличке DSCP-CoS вычисляется исходящий CoS, который влияет на выбор очереди (см. выше), и также пишется в тег 802.1q (если порт транковый). Важно помнить, что как только мы настроим доверие CoS, у нас также будет переписываться и DSCP (в соответстии с вычисленным значением). Вспоминаем схему с IP-телефоном 🙂
Вариант 2– то же, но с сохранением DSCP
специально для этого предусмотрен довесок к вышеуказанной команде
sw(config-if)#mls qos trust cos pass-through dscp
Вариант 3 – доверие DSCP
sw(config-if)#mls qos trust dscp
Internal DSCP берется напрямую из заголовка пакета. По табличке DSCP-CoS вычисляется исходящий CoS, который влияет на выбор очереди, и пишется в тег 802.1q (на транковом порту).
Для вариантов 4,5 предусмотрен недоверенный режим, который кстати, является дефолтным на 2950. Для всего входящего трафика назначается default CoS (который по умолчанию = 0), вычисляется Internal DSCP = 0, далее исходящий CoS = 0, соответственно влияя на выбор очереди. Теперь вопрос – запишутся ли эти нули в заголовки L2 и L3? На это влияет настройка CoS Override (которая по умолчанию выключена). При том, что по умолчанию default CoS = 0, и CoS Override disabled, 2950, вынутый из коробки и включенный в сеть, не портит маркировку проходящего трафика. Но стоит включить CoS Override, будем на выходе иметь обнуленную маркировку.
sw(config-if)#no mls qos trust
sw(config-if)#mls qos cos [0-7]
sw(config-if)#mls qos cos override
Настройка табличек преобразования (в глобальном конфиге):
sw(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56
Если на 5-й позиции (считая с нуля) стоит 46, то это означает, что CoS 5 -> DSCP 46
sw(config)#mls qos map dscp-cos 40 46 to 5
и так далее для всех 8 значений CoS
Типовая настройка
Резюмируя, приведу типовой конфиг порта:
sw(config-if)#switchport access vlan 10
sw(config-if)# switchport voice vlan 110
sw(config-if)#mls qos trust cos <- доверие CoS при наличии телефона
sw(config-if)#mls qos trust device cisco-phone
глобально:
sw(config)#wrr-queue bandwidth 10 40 10 0 <- конфигурим WRR, 4-я очередь приоритетная
sw(config)#wrr-queue cos-map 1 1 2 3
sw(config)#wrr-queue cos-map 2 4
sw(config)#wrr-queue cos-map 3 6 7
sw(config)#wrr-queue cos-map 4 5 <- направляем голос (CoS 5) в 4-ю очередь
sw(config)#mls qos map dscp-cos 0 8 16 24 32 46 48 56 <- преобразуем CoS 5 в DSCP EF
Замечу также, что 2950 – единственный свич, на котором не нужно давать глобальную команду mls qos (ее там просто нет). На всех остальных моделях – нужно.
Как можно посмотреть настройки QoS на порту:
sw#sh mls qos int fa0/15 FastEthernet0/15 trust state: not trusted trust mode: trust cos COS override: dis default COS: 0 pass-through: none trust device: cisco-phone
Еще один хинт — сравнивая строки trust state и trust mode, мы видим, что телефончег в данный момент отсутствует, то есть не подключен к свичу 🙂
Классификация и маркировка в 2950
Если нам нужно что-то произвольно отклассифицировать и отмаркировать, мы можем написать class-map, и в политике для этого класса выставить маркировку DSCP. Например, так:
access-list 101 permit <bla-bla-bla>
class-map test
match access-group 101
policy-map test
class test
set dscp 46
В принципе похоже на то, как это делается на маршрутизаторах. Но есть ряд ограничений:
- Не поддерживается несколько match в классе. Соответственно match-all/match-any теряет смысл
- В качестве условия match можно написать всего лишь:
- match dscp (тогда internal DSCP будет определяться этим значением)
- match access-group (классификация по аксесс-листу)
3. поддерживаются не все 64 возможных значения DSCP, а только из списка:
0 Match packets with default dscp (000000)
8 Match packets with CS1(precedence 1) dscp (001000)
10 Match packets with AF11 dscp (001010)
16 Match packets with CS2(precedence 2) dscp (010000)
18 Match packets with AF21 dscp (010010)
24 Match packets with CS3(precedence 3) dscp (011000)
26 Match packets with AF31 dscp (011010)
32 Match packets with CS4(precedence 4) dscp (100000)
34 Match packets with AF41 dscp (100010)
40 Match packets with CS5(precedence 5) dscp (101000)
46 Match packets with EF dscp (101110)
48 Match packets with CS6(precedence 6) dscp (110000)
56 Match packets with CS7(precedence 7) dscp (111000)
Это относится и к конфигурации DSCP во всех мапах
4. В аксесс-листе нельзя писать range (диапазон портов). Просто порт – можно.
5. В качестве действия в политике можно указать:
- set dscp (опять же их приведенного списка)
- police (в свою очередь, есть ограничения на количество полисеров на порту и на гранулярность полисинга)
Одним словом, 2950 является не таким уж и глупым железом. Но внимание – все приведенное относилось только к Enchanced Image. А что же со Standard Image? Вот что умеет этот «коммутатор для цветочного магазина»:
- нельзя делать trust dscp. Причем trust cos – можно
- настраивать очереди и назначение CoS на очереди – можно
- настраивать распознавание IP-телефона – можно
- таблички преобразования есть – дефолтные. Менять их нельзя.
- Никаких класс-мапов и политик, соответственно нельзя маркировать DSCP и полисить трафик.
Вот такая, коллеги, получилась моя первая статья по QoS на коммутаторах. Как говорится – не переключайте, оставайтесь с нами, следующая серия будет про семейство 2960/3560/3750. Если что, можно пинать, но несильно 🙂 Если будут комментарии/исправления/пожелания – пишите сюда или в личку на форуме.
--
С уважением,
Евгений Киселев aka Stratosphere
Метки: 2950, QoS, качество обслуживания, коммутаторы
Опубликовано: Маршрутизаторы и коммутаторы
Отлично, Жень! одна из лучших статей блога
Статья отличная, что и говорить!
Ты сам-то когда разродишься? Даешь соцсоревнование!
ЗЫ А вообще, это ты конечно на меня наехал 🙂 Буду тренироваться, чтобы переплюнуть Женю 🙂
Коллеги, спасибо вам за высокую оценку! для меня это маленькая победа над моей ленью-)) Будем дальше побеждать-)))
Сереж, мне кажется, Илюха не хотел тебя опустить, он же сказал «одна из лучших», то есть у меня пока одна, а у тебя их больше 20 (если не ошибаюсь). Так что тебя нам в ближайшем будушем пока не переплюнуть-))
Да это я так, троллю помаленьку 🙂
Илюхе меня обидеть вообще имхо unreal 🙂
я очень рад, что мне unreal тебя обидеть 🙂 но я вовсе не пытался тебя раздраконить 🙂 вот разве что сподвигнуть на новые статьи 🙂
сам когда рожу… я что-то отупел 🙂 надо срочно сесть за что-нибудь актуальное 🙂 но у меня еще базовый цикл про НАТ не дописан… В общем, Женька еще и меня катализатнул
Спасибо. Очень доходчиво.
Евгений, на будущее:
есть тэг «more» который позволяет публиковать на общей странице не всю статью, а пару абзацев, скрывая остальное под ссылкой «Читать далее»
Рекомендую пользоваться этим тэгом для удобства чтения стартовой страницы блога.
С уважением, Администратор
Честно говоря, не разобрался, как это делать. Нашел пиктограммку «more», но не понял как это работает — текст после этой вставки все равно отображается на той же самой странице. Не подскажите, как это правильно сделать?
Наверно, ты смотрел саму запись в блоге (После нажатия кнопки «Просмотреть запись»). Это ссылка
./blogs/?p=626
А работает этот тэг только на главной, т.е. видеть ты это будешь на
./blogs
А, все, дошло, спасибо, Сереж. Посмотрел — работает 🙂
Хорошая и нужная статья.
А по поводу 2950 и “он уже давно end of sale, зачем про него говорить?» скажу что моя контора (работаю в небольшом провайдере) использует 2950 на доступе. Это гораздо удобнее и иной раз надежней чем недорогие D-Link и Planet.
У меня С2960 wrr вообще не признаёт. Есть только вот такая радость
TestSwitch(config)#mls qos srr-queue input cos-map queue ?
enter cos-map input queue id
И ещё непонятно: в итоге требуется для 3 классов 8 policy (8 вариаций процентных отношений) прописать. А все возможности
TestSwitch(config-pmap-c)#police ?
Bits per second, in multiples of 1M
aggregate Choose aggregate policer for current class.
На 3750 дело также дальше этого не продвинулось. Делов IOS’е или я неверно тему поняла?
Приветствую!
Все верно, очередность на 2960 настраивается совсем не так, как на 2950. Про 2960 — отдельный цикл статей
http://www.anticisco.ru/blogs/?p=816#more-816
Правда, там пока только вводная часть + про классификацию и маркировку, про очередность еще не написал, но совсем-совсем скоро напишу. Там в одной команде задается распределение по очередям и по порогам сброса.
Про полисинг — тоже все верно, есть 2 варианта:
— указать максимальную скорость для класса
— привесить агрегатный полисер
Про полисинг тоже напишу скоро.
Приветствую! Ждем продолжения темы. На рисунке, где телефон, откуда у кадров хоста CoS со значением 7 или предполагается, что на хосте есть vlans?