Всем добрый день, хабровчане!

В предыдущей статье про QoS я рассказал о том, что такое политика приоритезации трафика и что это крайне полезная вещь при ограниченном емкостном ресурсе в телеком сетях операторов связи. Сегодня я хочу более детально рассказать с примерами, на что влияет корректная настройка QoS.

QoS занятный предмет - вроде он есть и вроде его нет. Обычно в сетях телеком операторов все сводится к шаблонным настройкам на том или ином сегменте сети, и если все настроено по шаблону, то приоритезация настроена - считается так. На самом деле это далеко не так. И как раз в момент созревания сомнений рождается вопрос - а как измерить то чего не видно? На помощь приходят измерительные комплексы и визуализация потока данных. В своем примере я покажу два инструмента - всем привычный Zabbix для визуализации очередей и измерительный комплекс IPProbe (ныне SkyLight) компании Accedian, который с помощью протокола TWAMP может создавать измерительные сессии в той или иной очереди и с высокой точность показывать ключевые показатели транспортной сети, такие как delay, jitter, packet loss, variance delay/jitter в направлении UL/DL по отдельности.

Итак начнем с проблемы. В одном из филиалов одного оператора связи пожаловались мобильщики на "транспорт". У них как только просаживаются KPI по радио, то во всем виноваты транспортники, корщики, но только не они. Жаловались на то, что страдает "голос". Т.е. недозвоны, колл-дропы, неразборчивая речь и прочие прелести жизни. После недолгого анализа и разворачивания систем визуализации, предположения подтвердились - не настроен QoS. При этом нужно сразу уточнить, что проблемы на транспортной сети действительно были в виде потерь пакетов (discards). Эти потери были связаны с не оптимально настроенными размерами буферов для той или иной очереди. Плюс к этому некорректная маркировка могла ремапить высокоприоритетный голосовой трафик CP/UP в более низкую очередь - отсюда и проблемы с соединениями, неразборчивой речью и т.д.

Хорошо - с теорией определились - как проверить? В дело вступает протокол TWAMP. Суть протокола в том, что некий источник (twamp sender) создает тестовую сессию с определенным pps, в нужной очереди, с нужным ttl, размером пакетов и прочими параметрами к twamp reflector. Пакеты отражаются от рефлектора и направляются обратно к сендеру. Задача сендера посчитать принятые пакеты - сколько потерялось, с какой задержкой и джиттером пришли, есть ли мисордеринг, вариативность, так еще и с различными просентилями, заданной скважностью.

Выглядят измерения так:

Итак, TWAMP настроили, Zabbix натравили - смотрим.

1 - потери пакетов в радиоинтерфейсе MLTN Ericsson. Естественно QoS в радио не настроен.

2 - потери на стыке MEN-RRL. Справедливости ради стоит сказать, что потери на МЕН только в низкоприоритетных очередях, и на голосовой сервис эта проблема никак не влияла. Но подлечить тоже стоило.

Итак, пошли лечить РРЛ - произвели корректную настройку QoS с доверием p-bit (L2) входящему трафику, что позволило РРЛ корректно распределить трафик по очередям, что видно по статистике самой РРЛ. При этом обратите внимание, что потери в очередях сохранились - в 1 и 2 очереди, что соответствует классам трафика AF1, AF2. Важно, что у нас нет потерь в пятой очереди и выше, т.к. именно пятая очередь обслуживает голосовой трафик.

Смотрим как распределение трафика в РРЛ повлияло на показатели. Сессия TWAMP была запущена от ядра сети к базовой станции - именно БС и была twamp reflector. т.е. измерение проводилось E2E от уровня коммутатора через всю трансмиссию к БС в очереди EF (там где находится голос).

Delay существенно сократился после 5 октября.

Уровень потерь пакетов снизился с 20% в пике до нуля. 100% packet loss 8 октября связан с отключением базовой станцией.

Теперь смотрим, как настройка QoS повлияла на конечных пользователей мобильной сети. Красной линией обозначен RAB_SETUP_FR_CS со снижением показателей более чем в два раза, при этом CDR_CS и объем голосового трафика в Эрлангах без изменений. RAB_SETUP_FR_CS - это показатель неуспешности соединений по протоколу RAB (Radio Access Bearer) в домене CS (голосовом). Как это выглядит в реальной жизни - вы набрали номер абонента и слышите тишину. После определенного тайм-аута три коротких гудка и сброс соединения. После этого вы набираете абонента снова. Процент считается как кол-во неуспешных соединений, деленное на общее кол-во попыток звонков. Про важность этого показателя. К примеру, базовая станция в день обслуживает 15000 звонков. 0,1% = 15 недозвонов. С помощью настройки QoS на РРЛ нам удалось снизить кол-во недозвонов до 7,5. Оставшиеся 0,05% связаны уже с коммутатором, MGW, радио параметрами самой БС.

А вот затравочка для следующей статьи про флуд в L2 сетях в картинках. Как с помощью оптимизации ТС снизить утилизацию интерфейсов без влияния на полезный трафик. Та разница, которую вы видите на картинке ниже - это паразитный трафик, вызванный флудом в L2 домене. Чудеса? Нет - кривые настройки сети.