QoS (пример) — различия между версиями

Материал из wiki
Перейти к: навигация, поиск
Строка 1: Строка 1:
 
+
== QoS. Пример работы с голосовым трафиком ==
 
Технологии QoS окружены множеством мифов и горой документации. Можно потратить уйму времени на штудирование пособий и статей, но так и не дойти до внятного лабораторного теста.
 
Технологии QoS окружены множеством мифов и горой документации. Можно потратить уйму времени на штудирование пособий и статей, но так и не дойти до внятного лабораторного теста.
  
Строка 8: Строка 8:
 
Итак, дана простая сеть. Два коммутатора cisco catalyst 2960 соединены 100-мегабитными портами и имеют 100-мегабитный канал в сеть кампуса. Для данных используется влан 50, сеть 10.50.0.0/24. В сети кампуса развернута voip телефония и голосовой трафик использует влан 100, сеть 10.11.12.0/24.
 
Итак, дана простая сеть. Два коммутатора 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
+
http://user.files.psu.ru/MoiseevVI/img/qos_empty.jpg
  
  
Строка 21: Строка 21:
 
Для загрузки канала воспользуемся утилитой iperf на компьютере 10.50.0.5.
 
Для загрузки канала воспользуемся утилитой iperf на компьютере 10.50.0.5.
  
iperf -u -c 10.50.0.6 -b 2000m -t 1200 -i 1 -P10 -w 64K
+
iperf -u -c 10.50.0.6 -b 2000m -t 1200 -i 1 -P10 -w 64K
  
 
Запуск с такими параметрами заставляет iperf генерировать трафик на скорости до 2000мбит/с по протоколу UDP в 10 потоков. Каждую секунду iperf будет сообщать, на какой скорости ему удается отсылать трафик. Можно ожидать, что такой поток трафика достаточен для переполнения промежуточных буферов. Заметить это можно по счетчикам порта. Выполним на левом коммутаторе команду
 
Запуск с такими параметрами заставляет iperf генерировать трафик на скорости до 2000мбит/с по протоколу UDP в 10 потоков. Каждую секунду iperf будет сообщать, на какой скорости ему удается отсылать трафик. Можно ожидать, что такой поток трафика достаточен для переполнения промежуточных буферов. Заметить это можно по счетчикам порта. Выполним на левом коммутаторе команду
  
show interface fa 0/23
+
show interface fa 0/23
  
 
Среди прочих счетчиков мы видим счетчик Output drops. Если емкости исходящих буферов недостаточно, счетчик будет постоянно увеличиваться.
 
Среди прочих счетчиков мы видим счетчик Output drops. Если емкости исходящих буферов недостаточно, счетчик будет постоянно увеличиваться.
Строка 42: Строка 42:
 
1.Включим QoS на коммутаторе.
 
1.Включим QoS на коммутаторе.
  
mls qos
+
mls qos
  
 
Делать это нужно аккуратно, т.к. в момент включения может на пару секунд пропасть трафик. Надо отслеживать, не скажется ли это негативно на прочих потоках трафика, т.к. общие буферы будут распределяться по иной схеме.
 
Делать это нужно аккуратно, т.к. в момент включения может на пару секунд пропасть трафик. Надо отслеживать, не скажется ли это негативно на прочих потоках трафика, т.к. общие буферы будут распределяться по иной схеме.
 +
 
2.Создадим аксесс-лист, описывающий «голосовой» трафик
 
2.Создадим аксесс-лист, описывающий «голосовой» трафик
  
ip access-list extended AGOO
+
ip access-list extended AGOO
 
 
 
   permit ip any 10.11.12.0 0.0.0.255
 
   permit ip any 10.11.12.0 0.0.0.255
 +
  permit ip 10.11.12.0 0.0.0.255 any
  
  permit ip 10.11.12.0 0.0.0.255 any
 
 
3.Создадим класс, срабатывающий по этому аксесс-листу:
 
3.Создадим класс, срабатывающий по этому аксесс-листу:
  
class-map CGOOD
+
class-map CGOOD
 +
  match access-group name AGOOD
  
match access-group name AGOOD
 
 
4.Создадим политику к данному классу, маркирующую трафик кодом приоритетной доставки «EF»:
 
4.Создадим политику к данному классу, маркирующую трафик кодом приоритетной доставки «EF»:
  
policy-map POLLY
+
policy-map POLLY
 
 
 
   class CGOOD
 
   class CGOOD
 
 
     set dscp EF
 
     set dscp EF
  
 
По-умолчанию, именно EF трафик попадает в приоритетную очередь.
 
По-умолчанию, именно EF трафик попадает в приоритетную очередь.
 +
 
5.На всех используемых интерфейсах, активируем приоритетную очередь (по-умолчанию она выключена)
 
5.На всех используемых интерфейсах, активируем приоритетную очередь (по-умолчанию она выключена)
  
priority-queue out  
+
priority-queue out  
 +
 
 
6.На всех интерфейсах применим политику маркировки (можно применить только на граничных интерфейсах).
 
6.На всех интерфейсах применим политику маркировки (можно применить только на граничных интерфейсах).
  
service-policy input POLLY
+
service-policy input POLLY
 +
 
 
7.Если все сделано верно, связь между телефонами снова станет нормальной.
 
7.Если все сделано верно, связь между телефонами снова станет нормальной.
  
   
+
  Логичным продолжением станет введение политики на менее приоритетный трафик - ограничение скорости. Сделать это можно используя функционал QoS - traffic policing. Нам потребуется определить класс неприоритетного трафика по аксесс-листу и наложить на него ограничение скорости.
 
 
Логичным продолжением станет введение политики на менее приоритетный трафик - ограничение скорости. Сделать это можно используя функционал QoS - traffic policing. Нам потребуется определить класс неприоритетного трафика по аксесс-листу и наложить на него ограничение скорости.
 
1.При помощи аксесс-листа опишем трафик между компьютерами:
 
  
ip access-list extended ABAD
+
8.При помощи аксесс-листа опишем трафик между компьютерами:
 +
 
 +
ip access-list extended ABAD
 +
  permit ip 10.50.0 0.0.0.255 10.50.0.0 0.0.0.255
  
permit ip 10.50.0 0.0.0.255 10.50.0.0 0.0.0.255
+
9.Создадим по этому аксесс-листу класс «плохого» трафика.
2.Создадим по этому аксесс-листу класс «плохого» трафика.
 
 
 
class-map CBAD
 
  
 +
class-map CBAD
 
   match access-group name ABAD
 
   match access-group name ABAD
3.В действующую политику допишем обработчик для нового класса трафика – разрешенная скорость 50 Мбит/с, всплеск 512000 Байт, при превышении – дроп:
 
  
policy-map POLLY
+
10.В действующую политику допишем обработчик для нового класса трафика – разрешенная скорость 50 Мбит/с, всплеск 512000 Байт, при превышении – дроп:
  
 +
policy-map POLLY
 
   class CBAD
 
   class CBAD
 
 
     police 50m 512000 exceed-action drop
 
     police 50m 512000 exceed-action drop
 +
exit
  
exit
+
11.Если все сделано правильно, трафик между хостами будет ограничен до 50 Мбит/с.
4.Если все сделано правильно, трафик между хостами будет ограничен до 50 Мбит/с.
 
 
 
 
  
 
Отметим, что используя только лишь ограничение скорости паразитного трафика, нам не удастся дать приоритет голосовому трафику. Дело в том, что скорости ограничивается по среднему значению за некоторый интервал времени. Внутри же этого периода усреднения трафик может многократно превышать указанное значение. Несмотря на кратковременность, такой всплеск может переполнить буфер. Такой эффект называют "микровсплеск". Хотя микровсплески не видны по усредненному значению скорости трафика на интерфейсе, они способны привести к потерям приоритетного трафика. Это означает, что без активации приоритетной очереди нашу задачу не решить.
 
Отметим, что используя только лишь ограничение скорости паразитного трафика, нам не удастся дать приоритет голосовому трафику. Дело в том, что скорости ограничивается по среднему значению за некоторый интервал времени. Внутри же этого периода усреднения трафик может многократно превышать указанное значение. Несмотря на кратковременность, такой всплеск может переполнить буфер. Такой эффект называют "микровсплеск". Хотя микровсплески не видны по усредненному значению скорости трафика на интерфейсе, они способны привести к потерям приоритетного трафика. Это означает, что без активации приоритетной очереди нашу задачу не решить.
  
   
+
  Мы показали, что, используя функционал QoS, можно добиться удовлетворительного качества передачи голосового трафика даже в сети с большим количеством фонового трафика. Также мы рассмотрели, как при помощи QoS ограничить полосу пропускания для менее приоритетного трафика.
 
 
Мы показали, что, используя функционал QoS, можно добиться удовлетворительного качества передачи голосового трафика даже в сети с большим количеством фонового трафика. Также мы рассмотрели, как при помощи QoS ограничить полосу пропускания для менее приоритетного трафика.
 
  
 
[[категория:Лекции]] [[категория:Сети]] [[категория:Cisco]] [[категория:VoIP]]
 
[[категория:Лекции]] [[категория:Сети]] [[категория:Cisco]] [[категория:VoIP]]

Версия 04:40, 18 ноября 2013

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.

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.

Нас интересует опция 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 ограничить полосу пропускания для менее приоритетного трафика.