В первой части статьи мы рассмотрели, как большая загрузка канала влияет на голосовой трафик. Хосты, способные загрузить промежуточный канал до предела, создают серьезные проблемы для передачи требовательного голосового трафика. Причина - недостаточный объем буферов портов.
Стоит отметить, что используя гипотетический коммутатор с гигантским размером буферов, проблему мы не решим. Трафик лишь будет буферизоваться на неопределенное время, а VoIP очень чувствителен к задержкам и опоздавшие пакеты принимать не будет.
Решением будет включение определенного функционала QoS.
Нас интересует опция LLQ - Low Latency Queueing или Priority Queueing. Включение этой опции активирует на порту так называемую "приоритетную" очередь. Это часть буфера обслуживаемая приоритетно. Если в ней есть хоть один пакет - он будет обработан коммутатором в первую очередь, не смотря на то, что в основном буфере еще много данных.
Чтобы воспользоваться преимуществами приоритетной очереди нам потребуется определить приоритетный трафик.
Трафик нужно описать аксесс-листом. Аксесс-лист включить в класс. И только после этого создать политику, маркирующую трафик кодом приоритетной доставки.
- Включим QoS на коммутаторе.
mls qos
Делать это нужно аккуратно, т.к. в момент включения может на пару секунд пропасть трафик. Надо отслеживать, не скажется ли это негативно на прочих потоках трафика, т.к. общие буферы будут распределяться по иной схеме.
- Создадим аксесс-лист, описывающий «голосовой» трафик
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
- Создадим класс, срабатывающий по этому аксесс-листу:
class-map CGOOD
match access-group name AGOOD
- Создадим политику к данному классу, маркирующую трафик кодом приоритетной доставки «EF»:
policy-map POLLY
class CGOOD
set dscp EF
По-умолчанию, именно EF трафик попадает в приоритетную очередь.
- На всех используемых интерфейсах, активируем приоритетную очередь (по-умолчанию она выключена)
priority-queue out
- На всех интерфейсах применим политику маркировки (можно применить только на граничных интерфейсах).
service-policy input POLLY
- Если все сделано верно, связь между телефонами снова станет нормальной.
Логичным продолжением станет введение политики на менее приоритетный трафик - ограничение скорости. Сделать это можно используя функционал QoS - traffic policing. Нам потребуется определить класс неприоритетного трафика по аксесс-листу и наложить на него ограничение скорости.
- При помощи аксесс-листа опишем трафик между компьютерами:
ip access-list extended ABAD
permit ip 10.50.0 0.0.0.255 10.50.0.0 0.0.0.255
- Создадим по этому аксесс-листу класс «плохого» трафика.
class-map CBAD
match access-group name ABAD
- В действующую политику допишем обработчик для нового класса трафика – разрешенная скорость 50 Мбит/с, всплеск 512000 Байт, при превышении – дроп:
policy-map POLLY
class CBAD
police 50m 512000 exceed-action drop
exit
- Если все сделано правильно, трафик между хостами будет ограничен до 50 Мбит/с.
Отметим, что используя только лишь ограничение скорости паразитного трафика, нам не удастся дать приоритет голосовому трафику. Дело в том, что скорости ограничивается по среднему значению за некоторый интервал времени. Внутри же этого периода усреднения трафик может многократно превышать указанное значение. Несмотря на кратковременность, такой всплеск может переполнить буфер. Такой эффект называют "микровсплеск". Хотя микровсплески не видны по усредненному значению скорости трафика на интерфейсе, они способны привести к потерям приоритетного трафика. Это означает, что без активации приоритетной очереди нашу задачу не решить.
Мы показали, что, используя функционал QoS, можно добиться удовлетворительного качества передачи голосового трафика даже в сети с большим количеством фонового трафика. Также мы рассмотрели, как при помощи QoS ограничить полосу пропускания для менее приоритетного трафика.
Это лишь маленький, но зато наглядный пример работы QoS в реальной сети.