QoS (пример) — различия между версиями
Moiseevvi (обсуждение | вклад) |
Moiseevvi (обсуждение | вклад) (→QoS. Policing) |
||
| (не показано 6 промежуточных версий этого же участника) | |||
| Строка 1: | Строка 1: | ||
| + | == QoS. Пример работы с голосовым трафиком == | ||
| + | === Введение === | ||
Технологии QoS окружены множеством мифов и горой документации. Можно потратить уйму времени на штудирование пособий и статей, но так и не дойти до внятного лабораторного теста. | Технологии QoS окружены множеством мифов и горой документации. Можно потратить уйму времени на штудирование пособий и статей, но так и не дойти до внятного лабораторного теста. | ||
| Строка 6: | Строка 8: | ||
В статье мы рассмотрим пример локальной сети на коммутаторах cisco catalyst 2960 с парой VoIP телефонов. Мы создадим нагрузку в сети и добьемся потерь голосового трафика, а затем проблема будет решена настройкой QoS. | В статье мы рассмотрим пример локальной сети на коммутаторах cisco catalyst 2960 с парой VoIP телефонов. Мы создадим нагрузку в сети и добьемся потерь голосового трафика, а затем проблема будет решена настройкой QoS. | ||
| + | === Топология === | ||
Итак, дана простая сеть. Два коммутатора 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 | |
| − | + | К каждому коммутатору в один из 100мбит портов подключен телефон. Будем считать, что в сети небольшой объем трафика и звонки между этими двумя телефонами проходят без проблем. | |
| − | К каждому коммутатору в | ||
Добавим в сеть два хоста, причем подключим их к гигабитным портам коммутаторов - так проще продемонстрировать эффект. Как известно, если трафик передается в коммутаторе с более высокоскоростного порта на менее скоросной - коммутатору придется кэшировать всплески трафика. Буферы на портах коммутатора небольшие. | Добавим в сеть два хоста, причем подключим их к гигабитным портам коммутаторов - так проще продемонстрировать эффект. Как известно, если трафик передается в коммутаторе с более высокоскоростного порта на менее скоросной - коммутатору придется кэшировать всплески трафика. Буферы на портах коммутатора небольшие. | ||
| Строка 22: | Строка 24: | ||
Для загрузки канала воспользуемся утилитой 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. Если емкости исходящих буферов недостаточно, счетчик будет постоянно увеличиваться. | ||
| + | |||
| + | === Нехватка буферов === | ||
Итак, во время разговора по VoIP между двумя телефонами, запустим iperf с хоста 10.50.0.5 на хост 10.50.0.6. Голос начнет прерываться. sh int покажет на перегруженном интерфейсе множество output drops. Телефоны могут потерять связь с сервером. | Итак, во время разговора по VoIP между двумя телефонами, запустим iperf с хоста 10.50.0.5 на хост 10.50.0.6. Голос начнет прерываться. sh int покажет на перегруженном интерфейсе множество output drops. Телефоны могут потерять связь с сервером. | ||
| Строка 38: | Строка 42: | ||
Решением будет включение определенного функционала QoS. | Решением будет включение определенного функционала QoS. | ||
| + | === QoS. Expedited forwarding === | ||
Нас интересует опция LLQ - Low Latency Queueing или Priority Queueing. Включение этой опции активирует на порту так называемую "приоритетную" очередь. Это часть буфера обслуживаемая приоритетно. Если в ней есть хоть один пакет - он будет обработан коммутатором в первую очередь, не смотря на то, что в основном буфере еще много данных. | Нас интересует опция LLQ - Low Latency Queueing или Priority Queueing. Включение этой опции активирует на порту так называемую "приоритетную" очередь. Это часть буфера обслуживаемая приоритетно. Если в ней есть хоть один пакет - он будет обработан коммутатором в первую очередь, не смотря на то, что в основном буфере еще много данных. | ||
Чтобы воспользоваться преимуществами приоритетной очереди нам потребуется определить приоритетный трафик. Трафик нужно описать аксесс-листом. Аксесс-лист включить в класс. И только после этого создать политику, маркирующую трафик кодом приоритетной доставки. | Чтобы воспользоваться преимуществами приоритетной очереди нам потребуется определить приоритетный трафик. Трафик нужно описать аксесс-листом. Аксесс-лист включить в класс. И только после этого создать политику, маркирующую трафик кодом приоритетной доставки. | ||
| + | |||
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 | ||
| − | |||
3.Создадим класс, срабатывающий по этому аксесс-листу: | 3.Создадим класс, срабатывающий по этому аксесс-листу: | ||
| − | class-map CGOOD | + | class-map CGOOD |
| + | 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. Policing === | |
| − | |||
Логичным продолжением станет введение политики на менее приоритетный трафик - ограничение скорости. Сделать это можно используя функционал QoS - traffic policing. Нам потребуется определить класс неприоритетного трафика по аксесс-листу и наложить на него ограничение скорости. | Логичным продолжением станет введение политики на менее приоритетный трафик - ограничение скорости. Сделать это можно используя функционал QoS - traffic policing. Нам потребуется определить класс неприоритетного трафика по аксесс-листу и наложить на него ограничение скорости. | ||
| − | |||
| − | |||
| − | |||
| − | permit ip 10.50.0 0.0.0.255 10.50.0.0 0.0.0.255 | + | 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 | match access-group name ABAD | ||
| − | |||
| − | + | 10.В действующую политику допишем обработчик для нового класса трафика – разрешенная скорость 50 Мбит/с, всплеск 512000 Байт, при превышении – дроп: | |
| + | policy-map POLLY | ||
class CBAD | class CBAD | ||
| − | |||
police 50m 512000 exceed-action drop | police 50m 512000 exceed-action drop | ||
| + | exit | ||
| − | + | 11.Если все сделано правильно, трафик между хостами будет ограничен до 50 Мбит/с. | |
| − | |||
| − | |||
| − | |||
Отметим, что используя только лишь ограничение скорости паразитного трафика, нам не удастся дать приоритет голосовому трафику. Дело в том, что скорости ограничивается по среднему значению за некоторый интервал времени. Внутри же этого периода усреднения трафик может многократно превышать указанное значение. Несмотря на кратковременность, такой всплеск может переполнить буфер. Такой эффект называют "микровсплеск". Хотя микровсплески не видны по усредненному значению скорости трафика на интерфейсе, они способны привести к потерям приоритетного трафика. Это означает, что без активации приоритетной очереди нашу задачу не решить. | Отметим, что используя только лишь ограничение скорости паразитного трафика, нам не удастся дать приоритет голосовому трафику. Дело в том, что скорости ограничивается по среднему значению за некоторый интервал времени. Внутри же этого периода усреднения трафик может многократно превышать указанное значение. Несмотря на кратковременность, такой всплеск может переполнить буфер. Такой эффект называют "микровсплеск". Хотя микровсплески не видны по усредненному значению скорости трафика на интерфейсе, они способны привести к потерям приоритетного трафика. Это означает, что без активации приоритетной очереди нашу задачу не решить. | ||
| − | |||
| − | |||
Мы показали, что, используя функционал QoS, можно добиться удовлетворительного качества передачи голосового трафика даже в сети с большим количеством фонового трафика. Также мы рассмотрели, как при помощи QoS ограничить полосу пропускания для менее приоритетного трафика. | Мы показали, что, используя функционал QoS, можно добиться удовлетворительного качества передачи голосового трафика даже в сети с большим количеством фонового трафика. Также мы рассмотрели, как при помощи QoS ограничить полосу пропускания для менее приоритетного трафика. | ||
[[категория:Лекции]] [[категория:Сети]] [[категория:Cisco]] [[категория:VoIP]] | [[категория:Лекции]] [[категория:Сети]] [[категория:Cisco]] [[категория:VoIP]] | ||
Текущая версия на 05:32, 22 мая 2014
Содержание
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.
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 ограничить полосу пропускания для менее приоритетного трафика.
