QoS (пример)
QoS. Пример работы с голосовым трафиком
Технологии QoS окружены множеством мифов и горой документации. Можно потратить уйму времени на штудирование пособий и статей, но так и не дойти до внятного лабораторного теста.
Цель статьи показать в лабораторных условиях пример конкретной проблемы, решаемой путем настройки QoS.
В статье мы рассмотрим пример локальной сети на коммутаторах cisco catalyst 2960 с парой VoIP телефонов. Мы создадим нагрузку в сети и добьемся потерь голосового трафика, а затем проблема будет решена настройкой QoS.
Итак, дана простая сеть. Два коммутатора cisco catalyst 2960 соединены 100-мегабитными портами и имеют 100-мегабитный канал в сеть кампуса. Для данных используется влан 50, сеть 10.50.0.0/24. В сети кампуса развернута voip телефония и голосовой трафик использует влан 100, сеть 10.11.12.0/24.
К каждому коммутатору в обин из 100мбит портов подключен телефон. Будем считать, что в сети небольшой объем трафика и звонки между этими двумя телефонами проходят без проблем.
Добавим в сеть два хоста, причем подключим их к гигабитным портам коммутаторов - так проще продемонстрировать эффект. Как известно, если трафик передается в коммутаторе с более высокоскоростного порта на менее скоросной - коммутатору придется кэшировать всплески трафика. Буферы на портах коммутатора небольшие.
В нашем случае это значит, что трафик, передающийся между двуми компьютерами с гигабитными портами, теоретически может переполнить буферы 100-мегабитных портов промежуточного канала. Это в свою очередь вызовет потери трафика, который не влез в буфер.
Проверить такое предположение очень просто - надо позвонить с одного телефона на другой, во время звонка прогрузить канал до максимума.
Для загрузки канала воспользуемся утилитой iperf на компьютере 10.50.0.5.
iperf -u -c 10.50.0.6 -b 2000m -t 1200 -i 1 -P10 -w 64K
Запуск с такими параметрами заставляет iperf генерировать трафик на скорости до 2000мбит/с по протоколу UDP в 10 потоков. Каждую секунду iperf будет сообщать, на какой скорости ему удается отсылать трафик. Можно ожидать, что такой поток трафика достаточен для переполнения промежуточных буферов. Заметить это можно по счетчикам порта. Выполним на левом коммутаторе команду
show interface fa 0/23
Среди прочих счетчиков мы видим счетчик Output drops. Если емкости исходящих буферов недостаточно, счетчик будет постоянно увеличиваться.
Итак, во время разговора по VoIP между двумя телефонами, запустим iperf с хоста 10.50.0.5 на хост 10.50.0.6. Голос начнет прерываться. sh int покажет на перегруженном интерфейсе множество output drops. Телефоны могут потерять связь с сервером.
Хосты, способные загрузить промежуточный канал до предела, создают серьезные проблемы для передачи требовательного голосового трафика. Причина - недостаточный объем буферов портов.
Стоит отметить, что используя гипотетический коммутатор с гигантским размером буферов, проблему мы не решим. Трафик лишь будет буферизоваться на неопределенное время, а VoIP очень чувствителен к задержкам и опоздавшие пакеты принимать не будет.
Решением будет включение определенного функционала QoS.
Нас интересует опция LLQ - Low Latency Queueing или Priority Queueing. Включение этой опции активирует на порту так называемую "приоритетную" очередь. Это часть буфера обслуживаемая приоритетно. Если в ней есть хоть один пакет - он будет обработан коммутатором в первую очередь, не смотря на то, что в основном буфере еще много данных.
Чтобы воспользоваться преимуществами приоритетной очереди нам потребуется определить приоритетный трафик. Трафик нужно описать аксесс-листом. Аксесс-лист включить в класс. И только после этого создать политику, маркирующую трафик кодом приоритетной доставки. 1.Включим QoS на коммутаторе.
mls qos
Делать это нужно аккуратно, т.к. в момент включения может на пару секунд пропасть трафик. Надо отслеживать, не скажется ли это негативно на прочих потоках трафика, т.к. общие буферы будут распределяться по иной схеме.
2.Создадим аксесс-лист, описывающий «голосовой» трафик
ip access-list extended AGOO permit ip any 10.11.12.0 0.0.0.255 permit ip 10.11.12.0 0.0.0.255 any
3.Создадим класс, срабатывающий по этому аксесс-листу:
class-map CGOOD match access-group name AGOOD
4.Создадим политику к данному классу, маркирующую трафик кодом приоритетной доставки «EF»:
policy-map POLLY class CGOOD set dscp EF
По-умолчанию, именно EF трафик попадает в приоритетную очередь.
5.На всех используемых интерфейсах, активируем приоритетную очередь (по-умолчанию она выключена)
priority-queue out
6.На всех интерфейсах применим политику маркировки (можно применить только на граничных интерфейсах).
service-policy input POLLY
7.Если все сделано верно, связь между телефонами снова станет нормальной.
Логичным продолжением станет введение политики на менее приоритетный трафик - ограничение скорости. Сделать это можно используя функционал QoS - traffic policing. Нам потребуется определить класс неприоритетного трафика по аксесс-листу и наложить на него ограничение скорости.
8.При помощи аксесс-листа опишем трафик между компьютерами:
ip access-list extended ABAD permit ip 10.50.0 0.0.0.255 10.50.0.0 0.0.0.255
9.Создадим по этому аксесс-листу класс «плохого» трафика.
class-map CBAD match access-group name ABAD
10.В действующую политику допишем обработчик для нового класса трафика – разрешенная скорость 50 Мбит/с, всплеск 512000 Байт, при превышении – дроп:
policy-map POLLY class CBAD police 50m 512000 exceed-action drop exit
11.Если все сделано правильно, трафик между хостами будет ограничен до 50 Мбит/с.
Отметим, что используя только лишь ограничение скорости паразитного трафика, нам не удастся дать приоритет голосовому трафику. Дело в том, что скорости ограничивается по среднему значению за некоторый интервал времени. Внутри же этого периода усреднения трафик может многократно превышать указанное значение. Несмотря на кратковременность, такой всплеск может переполнить буфер. Такой эффект называют "микровсплеск". Хотя микровсплески не видны по усредненному значению скорости трафика на интерфейсе, они способны привести к потерям приоритетного трафика. Это означает, что без активации приоритетной очереди нашу задачу не решить.
Мы показали, что, используя функционал QoS, можно добиться удовлетворительного качества передачи голосового трафика даже в сети с большим количеством фонового трафика. Также мы рассмотрели, как при помощи QoS ограничить полосу пропускания для менее приоритетного трафика.
