Cisco Catalyst 3750: QoS с DSCP EF вытащил голос из помоев корпоративной сети

IP-телефония - это та штука, которая отлично работает на демонстрации и начинает отвратительно себя вести через месяц после внедрения. Клиент позвонил с классической жалобой: «голос рвётся, разговоры обрываются, люди перезванивают по мобильному». Офис около восьмидесяти человек, SIP-транк к провайдеру, IP-телефоны на каждом столе, Cisco Catalyst 3750 как ядро коммутации.

Диагностика заняла примерно полдня и показала предсказуемую картину: в часы пик, когда сетевая нагрузка переваливала за 60% от полосы на аплинках, голосовой трафик начинал конкурировать с резервными копиями, файловыми трансферами и обновлениями антивируса. На коммутаторе не было настроено ровным счётом ничего - весь трафик шёл в одну очередь с равным приоритетом.

Что происходит без QoS

Голосовой трафик - это не поток данных, который можно немного придержать и потом выплеснуть. RTP-пакеты должны приходить равномерно, с задержкой не более 150 мс и джиттером не выше 30-40 мс. Всё что выходит за эти рамки - воспринимается как обрывы, щелчки, задержки или просто молчание.

Когда в одной очереди сидят одновременно голосовой RTP и, скажем, файловый сервер, который гоняет резервную копию в 40 ГБ, коммутатор не разбирается кто важнее. Он честно раздаёт буфер по очереди. Буфер переполняется - пакеты дропаются. Дропается голосовой пакет - пропал кусок разговора. Восстановить его нечем: RTP не переспрашивает.

Разметка трафика и очереди на 3750

Catalyst 3750 поддерживает несколько механизмов QoS: классификацию по CoS (Layer 2) и по DSCP (Layer 3), четыре очереди исходящего трафика, weighted tail drop и strict priority queue. Для голоса стандартная рекомендация - DSCP EF (Expedited Forwarding, значение 46): это специально выделенная метка для трафика с жёсткими требованиями к задержке.

Настройка шла в несколько шагов.

Первое - включили QoS глобально. Без mls qos коммутатор игнорирует все дальнейшие команды в этой части:

mls qos

Второе - настроили trust на портах, куда подключены IP-телефоны. Телефоны Cisco умеют сами проставлять DSCP EF в заголовки исходящих RTP-пакетов. Чтобы коммутатор им верил, нужно явно указать:

interface FastEthernet1/0/X
 mls qos trust dscp

Для телефонов сторонних производителей, которые метки не проставляют, добавили политику классификации по UDP-порту: SIP использует 5060, RTP занимает диапазон выше 16384. Это менее чисто, но работает.

Третье - настроили очереди. На 3750 исходящих очередей четыре, и одна из них может работать как strict priority - то есть обслуживается первой, пока в ней есть пакеты:

mls qos srr-queue output priority-queue 1 bandwidth 30
mls qos srr-queue output cos-map queue 1 threshold 3 5

Трафик с DSCP EF переводится в CoS 5 и попадает в очередь с приоритетом. Остальной трафик распределяется по трём оставшимся очередям с весовым планировщиком.

Четвёртое - политика на аплинке. Трафик между коммутатором и маршрутизатором тоже должен сохранять метки. Проверили, что на аплинк-портах стоит mls qos trust dscp, иначе метки теряются при выходе из коммутатора.

Что изменилось

Проверку делали под реальной нагрузкой - специально дождались утренних часов пик и параллельно запустили несколько крупных копирований по сети. До настройки джиттер в эти моменты прыгал до 80-120 мс и выше, пакеты дропались заметно. После - джиттер держится в районе 15-20 мс, потерь практически нет, разговоры не рвутся.

Клиентские жалобы исчезли в первый же день после изменений. Это, с одной стороны, приятно; с другой - немного обидно, потому что на диагностику и документирование ушло несколько часов, а на саму настройку - от силы час.

Несколько наблюдений по итогу:

• DSCP EF vs CoS. Если сеть однородная (только Cisco, всё на Layer 3 с trunk-портами), удобнее работать с DSCP: метки сохраняются между коммутаторами без пересчёта. CoS живёт только в пределах одного Ethernet-сегмента и теряется при маршрутизации.
• Trust boundary важнее, чем кажется. Если на порту нет mls qos trust dscp, коммутатор перезаписывает метки в 0. Полчаса потратили на то, чтобы понять почему политика не работает - оказалось, именно это.
• 30% полосы для голоса - с запасом. Даже при 80 одновременных пользователях голосовой трафик занимает небольшую долю от гигабитного аплинка. Strict priority queue с 30% - это комфортный запас без риска задушить остальной трафик при каком-нибудь нетипичном всплеске.

Открытый вопрос пока один: мониторинг качества голоса в реальном времени. Сейчас ориентируемся на жалобы пользователей и периодические замеры. Нормального инструмента для непрерывного контроля MOS или джиттера на уровне инфраструктуры у нас пока не настроено - это следующий шаг.

Для клиентов на сопровождении инфраструктуры настройка QoS под голос - теперь стандартная часть чеклиста при внедрении IP-телефонии. Без неё корпоративный голос работает примерно как: «мы запустили, а работает ли - узнаем от пользователей».