QoS для VoIP: приоритизация трафика в корпоративной сети

Привет! Меня зовут Семёнов Евгений Сергеевич, и я директор ITFresh. За мои пятнадцать с лишним лет в IT я успел настроить VoIP в сотнях компаний. Работали мы со всем подряд: от Asterisk, FreePBX, 3CX до самых разных облачных провайдеров — список, поверьте, внушительный. И знаете, почти всегда, куда бы мы ни пришли, первая жалоба звучала одинаково: «Звук просто рвётся, как только кто-то начинает качать файл!» Причина, на самом деле, всегда одна: полное отсутствие QoS. Но стоит один раз настроить QoS, и наш хаотичный до этого канал мгновенно становится предсказуемым. Голос идёт первым, а все остальные задачи терпеливо ждут своей очереди. В этой статье я поделюсь своим опытом, расскажу, как мы обычно настраиваем QoS на MikroTik, Cisco и, конечно же, внутри вашей корпоративной LAN.

Что такое QoS на пальцах

Что вообще такое QoS (Quality of Service)? Это не просто модное словечко, а целая система механизмов. Она управляет порядком и пропускной способностью вашего интернет-канала, решая, кто главнее в данный момент. Рано или поздно любой канал, будь он маленький или огромный, сталкивается с перегрузкой. Представьте: кто-то запустил бэкап на 500 Мбит/с, другой качает видео, третий открыл 1С через RDP — и тут VoIP начинает заикаться! Знакомо? QoS как раз и гарантирует, что ваш приоритетный трафик, например, голосовые звонки, никогда не будут стоять в этой очереди. Мы обеспечиваем им зелёный свет.

• Классификация — определение, к какому классу относится пакет (по порту, IP, DSCP-метке).
• Маркировка — установка DSCP/CoS значения в заголовок.
• Queuing — распределение пакетов по очередям разных приоритетов.
• Shaping / Policing — ограничение или сглаживание скорости неприоритетного трафика.

Стандарты DSCP для VoIP

QoS на MikroTik: Queue Tree с priority

MikroTik — это наш основной рабочий конёк, инструмент, который мы знаем вдоль и поперёк. На нём QoS обычно реализуется через Queue Tree, прямо на WAN-интерфейсе.

# Маркировка RTP (определяем голос по UDP-портам Asterisk)
/ip firewall mangle
add chain=prerouting protocol=udp dst-port=10000-20000 \
  action=mark-packet new-packet-mark=voip-rtp passthrough=no
add chain=prerouting protocol=udp src-port=10000-20000 \
  action=mark-packet new-packet-mark=voip-rtp passthrough=no

# Маркировка SIP-сигналинга
add chain=prerouting protocol=udp port=5060,5061 \
  action=mark-packet new-packet-mark=voip-sig passthrough=no
add chain=prerouting protocol=tcp port=5060,5061 \
  action=mark-packet new-packet-mark=voip-sig passthrough=no

# Установка DSCP для исходящего
add chain=postrouting packet-mark=voip-rtp action=change-dscp new-dscp=46
add chain=postrouting packet-mark=voip-sig action=change-dscp new-dscp=26

# Queue Tree
/queue tree
add name=WAN parent=ether1 max-limit=100M
add name=voip-rtp parent=WAN packet-mark=voip-rtp \
  priority=1 limit-at=10M max-limit=20M queue=pcq-voip
add name=voip-sig parent=WAN packet-mark=voip-sig \
  priority=2 limit-at=2M max-limit=4M
add name=other parent=WAN priority=7 limit-at=0 max-limit=80M

/queue type
add name=pcq-voip kind=pcq pcq-rate=100k pcq-classifier=dst-address,src-address

Когда мы ставим Priority=1, это значит, что пакеты из этой очереди имеют самый высокий приоритет. Они идут первыми! А PCQ? Он нужен, чтобы равномерно распределить полосу пропускания между всеми активными разговорами.

QoS на Cisco Catalyst / ISR

На оборудовании Cisco мы используем чуть иной подход. Здесь задействуется связка из class-map, policy-map и service-policy.

class-map match-any VOICE-RTP
 match dscp ef
 match access-group name VOICE-RTP-ACL
class-map match-any VOICE-SIG
 match dscp af31
 match access-group name VOICE-SIG-ACL
class-map match-any CRITICAL-DATA
 match dscp af21

policy-map WAN-OUT
 class VOICE-RTP
   priority percent 20
   set dscp ef
 class VOICE-SIG
   bandwidth percent 5
   set dscp af31
 class CRITICAL-DATA
   bandwidth percent 30
 class class-default
   bandwidth percent 45
   random-detect dscp-based

interface GigabitEthernet0/0/0
 service-policy output WAN-OUT

ip access-list extended VOICE-RTP-ACL
 permit udp any any range 16384 32767

Priority-класс на Cisco создаёт low-latency queue — очередь с минимальной задержкой. Это значит, что пакеты от голосового трафика обрабатываются всегда первыми, конечно, пока мы не превысили заданный процент от общей полосы.

QoS на коммутаторах доступа

Кстати, не забывайте и про локальную сеть! На коммутаторах доступа, будь то Cisco 2960 или MikroTik CRS, тоже нужно настроить trust DSCP. Это критично важно, иначе ваши драгоценные метки могут просто потеряться между устройствами, и вся настройка QoS пойдёт насмарку.

# Cisco
mls qos
interface GigabitEthernet0/10
 mls qos trust dscp
 switchport voice vlan 20

# MikroTik SwOS
/interface ethernet switch qos-hw-offloading
set switch1 enabled=yes

Современные IP-телефоны, такие как Yealink, Grandstream, Polycom, уже сами проставляют метку DSCP 46 в исходящие пакеты. Нам остаётся лишь одно — убедиться, что ни одно устройство по пути не сотрёт эту метку.

QoS через VPN

Если ваш офис подключён к АТС через защищённые туннели, например, WireGuard или IPSec, то здесь возникает отдельная задача: нам нужно «протащить» эти DSCP-метки сквозь туннель, чтобы они сохранились и продолжили работать.

# MikroTik WireGuard — pre-classify вручную
/ip firewall mangle
add chain=output out-interface=wg-hq action=change-dscp \
  new-dscp=46 packet-mark=voip-rtp passthrough=no

На VPN-сервере принимающая сторона должна уметь верить внешнему DSCP. В большинстве Linux-туннелей это включается опцией dscp-copy или аналогом.

Реальный кейс: 120 SIP-линий на производстве

Хочу рассказать про один очень показательный случай, он произошёл у нас в сентябре 2025 года. Наш клиент — крупное металлургическое производство, где-то в Подмосковье. Представьте, 320 сотрудников, 120 SIP-линий, а их Asterisk размещён в дата-центре МТС. Проблема, как вы догадались, была классической: «Звук постоянно рвётся по вечерам, когда запускаем бэкапы». Подумать только, канал на 500 Мбит/с, но он полностью загружался во время этих самых бэкапов! Мы провели замеры: до внедрения QoS целых 32% звонков имели MOS (Mean Opinion Score) ниже 3.5 — это просто катастрофа для операторов. Но после того, как наша команда настроила QoS на их пограничном MikroTik CCR2004 — мы выделили класс VOICE с priority=1 и грамотно сделали shaping остального трафика — ситуация изменилась кардинально. Теперь лишь 0.4% звонков опускались ниже MOS 3.5, а средний MOS подскочил до комфортных 4.3. Телефонные операторы вздохнули с облегчением, перестали жаловаться, а руководство, конечно, осталось очень довольно результатами. Кстати, вся работа обошлась в 48 000 руб., а сама настройка заняла всего один рабочий день, плюс мы ещё неделю вели тщательный мониторинг.

Мониторинг: как проверять QoS работает

Без постоянного мониторинга QoS — это не наука, это чистой воды вера. Чтобы вы были уверены в стабильности, мы всегда используем несколько подходов.

• Nagios/Icinga с плагином check_snmp_qos — показывает статистику очередей.
• Мы подключаем Grafana в связке с Prometheus, используя mikrotik-exporter или librenms. Это даёт наглядную картину всего происходящего в вашей сети.
• Периодически мы используем RTP Analyzer в Wireshark, делая захваты с зеркала порта. Так мы видим качество каждого звонка в деталях.
• Конечно, мы настраиваем MOS-мониторинг прямо на уровне Asterisk/FreePBX, получая данные через CDR. Это позволяет оценивать качество связи глазами ваших пользователей.

# Быстрая проверка DSCP в tcpdump
tcpdump -i any -n -v 'udp and port 5060' | grep -i tos
# Должно быть tos 0x68 (=104, что соответствует DSCP 26 AF31)

Частые ошибки

• Вот, скажем, настроили вы QoS. Только на роутере? Мы такое видели. А ведь коммутаторы, которым эти пакеты достаются дальше, запросто могут взять и сбросить все метки. В итоге, несмотря на все ваши усилия, вся идея приоритезации трафика просто рушится. Разве это эффективно?
• Неправильно указанные UDP-порты для маркировки? Это настоящая западня! Мы часто видим эту ошибку. Стандартные диапазоны ведь известны: Asterisk обычно работает с 10000 по 20000, а FreePBX предпочитает порты от 16384 до 32767. Если эти цифры перепутать при настройке, то качественной связи точно не ждите. Трафик просто не получит нужный приоритет.
• Выставить Priority 1 для всего трафика? Ну, это точно гарантирует, что QoS сразу же теряет смысл. Какой тогда приоритет? Получается, что у вас абсолютно всё важно. А если всё важно, значит, на самом деле, не важно ничего. Разве можно это назвать эффективной настройкой? Это просто обнуляет весь механизм QoS, который должен выделять самое ценное.
• Видим, что иногда QoS настраивают прямо на downstream-интерфейсе. Но подождите! Если ваш провайдер уже применяет свой шейпинг, то делать это на входящем трафике просто бесполезно. Эти пакеты уже прошли через его ограничения. Зачем дублировать? Действительно эффективно настроить QoS нужно именно на upstream-интерфейсе. Там вы влияете на трафик *до* того, как он покинет вашу сеть и столкнется с провайдерским шейпингом. Только так ваши приоритеты будут работать по-настоящему.
• Забытый VPN — туннель съедает метки.

FAQ — QoS для VoIP

Зачем нужен QoS, если канал 1 Гбит/с?

QoS нужен не на внутреннем канале, а на узком месте — обычно WAN. При закачке архива на 200 Мбит/с в полноскоростной канал пакеты VoIP начинают тормозить.

Что такое DSCP и зачем он?

DSCP — метка приоритета в IP-заголовке. Стандарт для VoIP — DSCP EF (46). Сигналинг SIP — DSCP AF31 (26).

Достаточно ли только WAN-QoS?

В идеале — нет, QoS должен быть сквозным. Но на практике 80% проблем решается настройкой только на WAN-интерфейсе.

Сколько полосы резервировать под голос?

По 100 кбит/с на разговор для G.711 и 30 кбит/с для G.729. Плюс 15% на накладные расходы.

QoS работает через VPN?

Да, если настроить pre-classify. DSCP-метки по умолчанию копируются во внешний IP-заголовок туннеля.