Базовая настройка Mikrotik с нуля для работы в VoIP-сетях часть 2

Главная практическая цель внедрения VLAN — локализация последствий сетевых аномалий (петли, штормы, неисправные устройства) и исключение «падения» всей сети сразу. Ethernet не рассчитан на петли и широковещательные шторма; сегментация разделяет broadcast-домены и ограничивает зону поражения одним классом устройств.

Дополнительные эффекты (бенефиты) сегментации:

• логическое разделение трафика и упрощение диагностики;
• повышение безопасности (минимизация «перебора»/сканирования соседних сегментов);
• независимое распространение профильных настроек (QoS, DHCP-опции);
• удобное управление критичными участками (например, отдельный VLAN для колл-центра).

Практика выделения критичных сегментов

Если есть высоконагруженный колл-центр, телефоны операторов должны быть вынесены в отдельный voice-VLAN от «офисных» аппаратов. Аварии уровня «петля на этаже» не должны приводить к остановке колл-центра. В особо критичных сценариях допустима модель «микросегментации» вплоть до «один телефон — один VLAN», если это экономически оправдано.

Способы назначения voice-VLAN на IP-телефонах

Ручная настройка на терминалах
Универсальный способ, совместим практически со всеми аппаратами. Требует минимальной подготовки сети (tagged-транк на порт с телефоном и untagged для пользовательского ПК, если он включается «за телефоном»). Минусы — трудоёмкость и человеческий фактор.

Provisioning-конфиги через DHCP/TFTP/HTTP(S)
Телефон получает по DHCP адрес сервера конфигурации (опции 66/67, 150 и т. п.), загружает персональный конфиг по MAC-адресу, перезагружается и применяет нужный VLAN. Схема типична, удобна в массовых развёртываниях, хорошо сочетается с каталогами (например, AD) для централизованного управления.

DHCP Option 132 (VLAN ID)
Если терминал поддерживает, по опции 132 передаётся идентификатор VLAN; телефон «перепрыгивает» в нужный сегмент после получения адреса в «общей» сети. Решение двухэтапное (сначала базовый DHCP, затем переход в voice-VLAN), зависит от реализации у вендора.

LLDP-MED (Link Layer Discovery Protocol – Media Endpoint Discovery)
Коммутатор объявляет «голосовой» VLAN на порту; телефон автоматически помещает свой голосовой интерфейс в этот VLAN. Типовой профиль — tagged voice-VLAN + untagged data-VLAN для ПК «за телефоном». Поддержка зависит от модели телефона; у массовых производителей (например, Yealink, Fanvil, Cisco) LLDP-MED обычно доступен. Включение LLDP-MED на коммутаторе следует ограничивать портами с телефонами (списки интерфейсов, порт-профили).

Пояснение по портам
На порту коммутатора, к которому подключён телефон с ПК «за ним», обычно настраивается:

• tagged: VLAN voice (например, 11) — для самого телефона;
• untagged (access): VLAN data (например, 12) — для ПК.
  ПК дополнительных настроек не требует; телефон получает voice-VLAN через LLDP-MED/конфиг и отправляет голосовой трафик с тегом, а ПК остаётся в «данных» без тега.

Автоматизация по OUI (MAC-префиксам): когда это не лучший выбор

Иногда на коммутаторах создают правила, помещающие кадры в нужный VLAN по OUI производителя (первые 24 бита MAC). Метод «для ленивых» и нередко приводит к хаосу:

• часто ограничено число правил;
• у вендоров множество OUI;
• реализация может быть процессорной (при нагрузке поведение деградирует).

На MikroTik аналог реализуется через switch rule (совпадение src-mac по маске → new-vlan-id). Рабоче-технически, но решение не «красивое» и хрупкое. Рекомендованы LLDP-MED/802.1X/централизованный provisioning.

802.1p (PCP) и приоритеты кадров

В VLAN-теге есть поле PCP (0–7). В типовой практике для голосового трафика используют повышенный приоритет (часто PCP=5). Это позволяет коммутаторам с аппаратной поддержкой QoS обслуживать RTP/сигнализацию раньше «обычного» трафика. Привязка к очередям зависит от вендора; цель — гарантировать низкую задержку и джиттер для голоса.

802.1X для телефонии: почему стоит применять

802.1X обеспечивает сетевой доступ по факту аутентификации на порту. Ключевое преимущество для телефонии — возможность динамического назначения VLAN по классу устройства/группе, без ручной настройки портов. Логика:

• на порту включена 802.1X-аутентификация;
• RADIUS (NPS/FreeRADIUS и др.) по атрибутам (тип устройства, группа) возвращает нужный VLAN;
• телефон попадает в «свой» voice-VLAN; при необходимости группы (например, «Call-center») получают отдельный VLAN/политику.

Нюансы телефонов
Поддержка EAP-методов у терминалов неоднородна; нередко для телефонов применяют MAC Authentication Bypass (MAB) — аутентификация по MAC как имени/паролю. Формат MAC для RADIUS (с двоеточиями/без) выбирается под конкретный сервер (в NPS удобнее без двоеточий). Обязательно настроить «что делать при ошибке»: гостевой VLAN для устройств без 802.1X, fallback при недоступности RADIUS и т. п.

QoS (качество обслуживания): что реально делает и чего не делает

QoS не «ускоряет» SIP/RTP. Он распределяет дефицитную ёмкость канала, выделяя гарантированную полосу для важного трафика и отбирая её у второстепенного. Метафора — «коридор для общественного транспорта»: чтобы автобус шёл ровно, кому-то придётся стоять в пробке.

Буферы и классификация

В классической (программной) реализации очереди живут в памяти маршрутизатора: входящий поток маркируется, раскладывается по классам, в дефиците — «слабые» очереди дропаются первыми. На современных коммутаторах (CRS2 и новее) доступен аппаратный QoS с очередями на switch-chip — эффективнее для L2/L2.5.

«Лучшее усилие» (Best Effort) vs покупка пропускной способности

Если канал к интернету узкий (например, 10 Мбит/с на выход при 300+ Мбит/с внутри), QoS спасёт голос, но рабочие пакеты других систем будут отбрасываться. Если в магистрали идёт только «рабочий» трафик (DC ↔ офис), иногда рациональнее расширить канал, чем «резать» производственные пакеты.

LTE и плавающие медиумы

На LTE/5G верхняя граница скорости нестабильна. Классический приоритет с отсечкой «от верхней полки» работает плохо. Компромисс — выделить отдельный канал/второго оператора и увезти туда только телефонию (и, при необходимости, управление).

Расчёт гарантии для голоса

Гарантированная полоса для RTP рассчитывается просто:
число одновременных каналов × ~80–100 Кбит/с на канал (G.711 с оверхедом; для кодеков сжатия — меньше).
Пример: оператор выделяет до 30 SIP-каналов → ~3 Мбит/с гарантии под голос. Это не «потолок», а низ, ниже которого голоса «не режутся».

Классификация трафика: общая логика

Рациональный путь — сначала определить и пометить всё нужное (SIP, RTP, связь с Asterisk, сервисы управления), а всё неразмеченное считать низкоприоритетным «фоном». Попытки «ловить торренты» по порту обречены: широкие UDP-диапазоны RTP совпадают с поведенческими паттернами p2p. Если важное попало в «фон» — добавить отдельное правило разметки и поднять класс. Несколько итераций — и профиль QoS стаби

MikroTik RouterOS: базовые приёмы для телефонии

Отключение FastTrack

FastTrack обходится без большинства обработчиков, включая очереди. Для работы QoS FastTrack нужно отключить (или исключить из него телефонию).

Simple Queues: быстрый старт

• «Родитель» — общая полоса к интернету (например, 10 Мбит/с).
• Отдельная Simple Queue для IP сервера Asterisk (выдать гарантию/ограничение, привязать к родителю).
• «Остальные» — агрегированная очередь с PCQ (pcq-upload/download-default) для честного деления между IP.
• Важно: Simple Queues обрабатываются сверху вниз — специфичные правила выше «общих».

Queue Tree + маркировка

Для сложных сценариев (несколько провайдеров, несколько VLAN, тонкая приоритизация RTP/сигналации, управление) применяются mangle-правила для маркировки (DSCP/connection/packet marks) и деревья очередей. Это даёт тонкий контроль за классами и полосу гарантии/максимума для каждого класса.

Аппаратный QoS на коммутаторах MikroTik

В ветках RouterOS 7.x для CRS2/некоторых новых моделей доступен Switch QoS (очереди на чипе) — эффективно для L2 между коммутаторами, позволяет разгрузить CPU. Конфигурация — через CLI в разделе interface/switch qos.

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

Максимальный приоритет следует отдавать управлению (доступ к устройствам, протоколы администрирования). В противном случае при перегрузке можно потерять контроль над сетью. Голос — следующий класс. Видео и остальной трафик — ниже. Это снижает риск, что высокочастотные «фоновые» потоки (включая p2p) «задавят» сигнализацию и RTP чисто числом пакетов.

Организационные замечания и практические риски

• Человеческий фактор (ошибки коммутации, «петли», неисправные устройства) — ключевой источник аварий; VLAN-сегментация и протоколы петле-детекции (RSTP, Loop Detection) обязательны. Если коммутатор «падает» от петли внутри одного VLAN — оборудование следует заменить.
• Поддержка LLDP-MED/802.1X — проверяется по моделям телефонов заранее; в смешанных парках предусмотреть промежуточные схемы (provisioning, DHCP-опции, MAB).
• Гостевые/ошибочные сценарии 802.1X — документируются: куда помещать устройство без клиента 802.1X, куда — при недоступном RADIUS.
• Колл-центр — всегда отдельный VLAN и класс QoS; допуски по отказоустойчивости выше, чем у «офисных» телефонов.

Итоговые рекомендации

1. Разделить голосовые устройства на отдельные VLAN, критичные группы (колл-центры) — в автономные сегменты.
2. Назначать voice-VLAN по LLDP-MED либо централизованным provisioning’ом; DHCP Option 132 использовать только там, где поддерживается терминалами.
3. Внедрять 802.1X с RADIUS и динамическим VLAN; для телефонов без полноценного EAP — MAB.
4. Маркировать голос (PCP/DSCP) и настроить QoS, обеспечивая гарантию под расчётную ёмкость RTP.
5. На MikroTik отключить FastTrack для трафика, проходящего через очереди; для «быстрого старта» применить Simple Queues + PCQ, для тонкой настройки — Queue Tree.
6. Управление сетью — максимальный приоритет; голос — следующий.
7. При LTE/«плавающей» среде — выделять отдельный канал под телефонию либо повышать физическую ёмкость; не полагаться на классический QoS без верхней границы.
8. Регулярно тестировать отказоустойчивость: петли, падение RADIUS, отсутствие LLDP-MED, перезапуск телефонов, деградация каналов.