Продвинутая маршрутизация и QoS на Mikrotik: как мы спасли VoIP в колл-центре на 150 операторов

Колл-центр «КоллЦентр» — 150 операторов, 3 этажа, Asterisk PBX, два канала интернет (основной 500 Мбит/с, резервный 200 Мбит/с). Маршрутизатор — Mikrotik CCR1036-8G-2S+, RouterOS 7.14. Проблема: в пиковые часы (11:00-14:00 и 16:00-18:00) голос рвётся, клиенты жалуются на эхо и задержки.

Первичная диагностика показала катастрофу:

# Проверяем текущую загрузку интерфейсов
/interface monitor-traffic ether1 once
# tx-bits: 487 Mbps / rx-bits: 312 Mbps — канал забит на 97%

# Смотрим активные соединения
/ip firewall connection print count-only
# 42847 — слишком много для 150 операторов

# Проверяем, есть ли QoS
/queue simple print
# Результат: пусто
/queue tree print
# Результат: пусто

Никакого QoS. 150 SIP-телефонов конкурируют за полосу с торрентами, YouTube и обновлениями Windows. VoIP-трафик (SIP + RTP) занимает всего 3-5 Мбит/с, но ему нужна стабильная задержка <150 мс и jitter <30 мс. В текущей ситуации jitter доходил до 200 мс.

В Mikrotik два механизма управления трафиком: Simple Queue и Queue Tree. Для нашей задачи подходит только Queue Tree по нескольким причинам:

• Simple Queue — привязана к конкретному IP/подсети, работает как плоский лимитер. Для 150 операторов пришлось бы создать 150 правил.
• Queue Tree — иерархическая структура (HTB — Hierarchical Token Bucket), позволяет приоритизировать классы трафика: VoIP > бизнес > обычный > bulk.

Наша схема QoS:

# Структура очередей (Queue Tree с HTB):
#
# Root (500 Mbps)
# ├── VoIP (priority 1, 50 Mbps guaranteed, 100 Mbps max)
# ├── Business (priority 3, 200 Mbps guaranteed, 400 Mbps max)
# │   ├── CRM (50 Mbps)
# │   ├── Email (50 Mbps)
# │   └── Web-apps (100 Mbps)
# ├── Default (priority 5, 150 Mbps guaranteed, 300 Mbps max)
# └── Bulk (priority 8, 50 Mbps guaranteed, 200 Mbps max)
#     ├── Updates (30 Mbps)
#     └── Downloads (20 Mbps)

Ключевая идея HTB: каждый класс получает гарантированную полосу (CIR — Committed Information Rate). Если класс не использует свою полосу — она временно перераспределяется другим классам. Но как только VoIP-трафик появляется, он немедленно получает свою гарантированную полосу обратно.

Прежде чем ставить приоритеты, нужно пометить трафик. В Mikrotik это делается через mangle rules. Мы классифицируем пакеты по connection-mark и packet-mark:

# Шаг 1: Маркируем соединения (connection-mark)

# VoIP: SIP (порт 5060) + RTP (порты 10000-20000) + сеть телефонов
/ip firewall mangle
add chain=prerouting src-address=10.10.50.0/24 protocol=udp \
    dst-port=5060 action=mark-connection new-connection-mark=voip_conn passthrough=yes
add chain=prerouting src-address=10.10.50.0/24 protocol=udp \
    dst-port=10000-20000 action=mark-connection new-connection-mark=voip_conn passthrough=yes
add chain=prerouting dst-address=10.10.50.0/24 protocol=udp \
    src-port=5060 action=mark-connection new-connection-mark=voip_conn passthrough=yes
add chain=prerouting dst-address=10.10.50.0/24 protocol=udp \
    src-port=10000-20000 action=mark-connection new-connection-mark=voip_conn passthrough=yes

# CRM: сервер CRM 10.10.10.50
add chain=prerouting dst-address=10.10.10.50 action=mark-connection \
    new-connection-mark=crm_conn passthrough=yes
add chain=prerouting src-address=10.10.10.50 action=mark-connection \
    new-connection-mark=crm_conn passthrough=yes

# Bulk: обновления Windows, антивирус, торренты
add chain=prerouting protocol=tcp dst-port=80,443 \
    connection-bytes=5000000-0 action=mark-connection \
    new-connection-mark=bulk_conn passthrough=yes comment="Large downloads >5MB"

# Шаг 2: Маркируем пакеты (packet-mark) на основе connection-mark
add chain=prerouting connection-mark=voip_conn action=mark-packet \
    new-packet-mark=voip_pkt passthrough=no
add chain=prerouting connection-mark=crm_conn action=mark-packet \
    new-packet-mark=crm_pkt passthrough=no
add chain=prerouting connection-mark=bulk_conn action=mark-packet \
    new-packet-mark=bulk_pkt passthrough=no
add chain=prerouting action=mark-packet \
    new-packet-mark=default_pkt passthrough=no comment="Everything else"

Важный трюк: правило для bulk-трафика использует connection-bytes=5000000-0, что маркирует только соединения, передавшие больше 5 МБ. Короткие HTTP-запросы (CRM, почта) остаются в классе default или business.

Теперь создаём дерево очередей. Порядок важен: сначала root, затем дочерние:

# Root queue на WAN-интерфейсе
/queue tree
add name=root_download parent=global max-limit=500M
add name=root_upload parent=global max-limit=500M

# VoIP — наивысший приоритет
add name=voip_down parent=root_download packet-mark=voip_pkt \
    limit-at=50M max-limit=100M priority=1 queue=default
add name=voip_up parent=root_upload packet-mark=voip_pkt \
    limit-at=50M max-limit=100M priority=1 queue=default

# Business — средний приоритет
add name=business_down parent=root_download packet-mark=crm_pkt \
    limit-at=200M max-limit=400M priority=3 queue=default
add name=business_up parent=root_upload packet-mark=crm_pkt \
    limit-at=100M max-limit=200M priority=3 queue=default

# Default — всё остальное
add name=default_down parent=root_download packet-mark=default_pkt \
    limit-at=150M max-limit=300M priority=5 queue=default
add name=default_up parent=root_upload packet-mark=default_pkt \
    limit-at=80M max-limit=200M priority=5 queue=default

# Bulk — низший приоритет (обновления, большие скачивания)
add name=bulk_down parent=root_download packet-mark=bulk_pkt \
    limit-at=50M max-limit=200M priority=8 queue=default
add name=bulk_up parent=root_upload packet-mark=bulk_pkt \
    limit-at=20M max-limit=100M priority=8 queue=default

Параметр limit-at — гарантированная полоса (CIR). max-limit — максимум, если есть свободная полоса. priority от 1 (высший) до 8 (низший) — определяет, кто получит свободную полосу первым.

Проблема: один оператор может забить весь VoIP-класс, если его телефон сбоит и шлёт мусорный трафик. Решение — PCQ (Per Connection Queue), который честно делит полосу между потоками:

# Создаём PCQ-очередь для справедливого распределения
/queue type
add name=pcq-voip kind=pcq pcq-rate=2M pcq-classifier=src-address \
    pcq-total-limit=5000 pcq-burst-rate=3M pcq-burst-threshold=1500K \
    pcq-burst-time=10s

add name=pcq-default-down kind=pcq pcq-rate=10M pcq-classifier=dst-address \
    pcq-total-limit=50000
add name=pcq-default-up kind=pcq pcq-rate=5M pcq-classifier=src-address \
    pcq-total-limit=50000

# Применяем PCQ к VoIP-очередям
/queue tree
set voip_down queue=pcq-voip
set voip_up queue=pcq-voip
set default_down queue=pcq-default-down
set default_up queue=pcq-default-up

DSCP-маркировка нужна, если между вами и SIP-провайдером есть маршрутизаторы, которые тоже поддерживают QoS. Стандарт для VoIP — EF (Expedited Forwarding, DSCP 46):

# Маркируем VoIP-пакеты DSCP EF (46) для транзитных маршрутизаторов
/ip firewall mangle
add chain=postrouting packet-mark=voip_pkt action=change-dscp \
    new-dscp=46 passthrough=yes comment="DSCP EF for VoIP"

# Маркируем CRM DSCP AF21 (18) — assured forwarding
add chain=postrouting packet-mark=crm_pkt action=change-dscp \
    new-dscp=18 passthrough=yes comment="DSCP AF21 for CRM"

# Bulk получает DSCP CS1 (8) — scavenger class
add chain=postrouting packet-mark=bulk_pkt action=change-dscp \
    new-dscp=8 passthrough=yes comment="DSCP CS1 for bulk"

Настроив QoS, нужно видеть, как он работает. Mikrotik поддерживает Traffic Flow (аналог Netflow), который экспортирует данные о потоках в коллектор:

# Включаем Traffic Flow (Netflow v9)
/ip traffic-flow
set enabled=yes interfaces=ether1,ether2 cache-entries=16k \
    active-flow-timeout=1m inactive-flow-timeout=15s

/ip traffic-flow target
add dst-address=10.10.10.100 port=2055 version=9

# На сервере 10.10.10.100 установлен ntopng для визуализации
# docker run -d --name ntopng -p 3000:3000 \
#   --net=host ntop/ntopng:stable \
#   -i ether1 -F "nprobe;zmq;tcp://127.0.0.1:5556"

Также полезен встроенный мониторинг очередей:

# Мониторинг загрузки очередей в реальном времени
/queue tree print stats
# Показывает bytes, packets, queued-bytes, dropped для каждой очереди

# Скрипт для логирования статистики QoS каждые 5 минут
/system scheduler
add name=qos-stats interval=5m on-event={
    :local voipRate [/queue tree get voip_down rate]
    :local voipDropped [/queue tree get voip_down dropped]
    :local defaultRate [/queue tree get default_down rate]
    :log info "QoS stats: VoIP=$voipRate dropped=$voipDropped Default=$defaultRate"
}

После запуска мы увидели, что VoIP-очередь ни разу не дропнула пакеты (dropped=0), а bulk-очередь при пиковой нагрузке сбрасывает около 2% пакетов — именно так и должно быть.

Написали несколько скриптов для автоматизации типовых задач:

1. Автоматический failover на резервный канал с приоритизацией VoIP:

# Скрипт проверки основного канала и переключения
/system scheduler
add name=wan-check interval=30s on-event={
    :local pingResult [/ping 8.8.8.8 count=3 interface=ether1 as-value]
    :if ([:len $pingResult] = 0) do={
        # Основной канал мёртв — переключаем VoIP на резервный
        /ip route set [find comment="primary-wan"] disabled=yes
        /ip route set [find comment="backup-wan"] disabled=no
        # Сужаем QoS под 200 Мбит резервного канала
        /queue tree set root_download max-limit=200M
        /queue tree set root_upload max-limit=200M
        # VoIP гарантия остаётся прежней
        /queue tree set voip_down limit-at=50M max-limit=80M
        # Остальное урезаем
        /queue tree set bulk_down limit-at=10M max-limit=30M
        :log warning "WAN failover: switched to backup, QoS adjusted"
    } else={
        # Основной канал жив — возвращаем
        /ip route set [find comment="primary-wan"] disabled=no
        /ip route set [find comment="backup-wan"] disabled=yes
        /queue tree set root_download max-limit=500M
        /queue tree set root_upload max-limit=500M
        /queue tree set voip_down limit-at=50M max-limit=100M
        /queue tree set bulk_down limit-at=50M max-limit=200M
    }
}

2. Управление полосой по расписанию:

# В рабочие часы (9:00-19:00) — строгий QoS
/system scheduler
add name=qos-work-hours start-time=09:00:00 interval=1d on-event={
    /queue tree set bulk_down max-limit=50M
    /queue tree set bulk_up max-limit=20M
    :log info "QoS: work hours mode — bulk traffic limited"
}

# Вне рабочих часов — ослабляем ограничения
add name=qos-off-hours start-time=19:00:00 interval=1d on-event={
    /queue tree set bulk_down max-limit=400M
    /queue tree set bulk_up max-limit=200M
    :log info "QoS: off hours mode — bulk traffic unrestricted"
}

После внедрения QoS на Mikrotik ситуация изменилась кардинально:

Главный урок: Mikrotik — мощнейший инструмент для управления трафиком, но без правильной архитектуры QoS (mangle → queue tree → PCQ) его возможности не раскрываются. Если у вас проблемы с качеством VoIP или приоритизацией корпоративного трафика — обращайтесь к нам в itfresh.ru.