Просмотр исходного текста страницы 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.

http://user.files.psu.ru/MoiseevVI/img/qos_empty.jpg


К каждому коммутатору в один из 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.

=== QoS. Expedited forwarding ===
Нас интересует опция 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. Policing ===
Логичным продолжением станет введение политики на менее приоритетный трафик - ограничение скорости. Сделать это можно используя функционал 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 ограничить полосу пропускания для менее приоритетного трафика.

[[категория:Лекции]] [[категория:Сети]] [[категория:Cisco]] [[категория:VoIP]]