И снова здравствуйте, господа и дамы!
Сегодня я расскажу об очень ресурсоемкой теме. Тема с названием - внедрение QoS и политики приоритезации трафика в сетях Telco.
С чего все началось? Дело в том, что примерно до 2010 года все телеком операторы жили припеваючи, не зная проблем с технологией Ethernet, и строили свои сети по технологии SDH/Sonet. Суть этой технологии проста как две копейки - с помощью мультиплексирования потоков E1, которые в свою очередь, состоят из 32 таймслотов, создается канал связи с временным разделением фрэймов. Т.е. есть стандартная величина потока Е1 - 2.048 мб/с, который содержит 32 таймслота по 64 кб/с. Далее некоторое количество потоков Е1 мультиплексируется в базовые уровни информационных структур STM-1, STM-16, STM-64 STM-256, что соответствует скоростям 155 мб/с, 2.5 Гб/с, 10 Гб/с, 40 Гб/с. Это значит, что на клиентском интерфейсе мультиплексора под одно клиентское включение выделили 3 таймслота (192 кб/с), и этот клиент не сможет отобрать емкость в основном канале свыше, чем 192 кб/с. Но в этой технологии есть ряд проблем, которые не дали ей развиться после 2010 года - дороговизна оборудования, худшая масштабируемость по сравнению с Ethernet сетями, невозможность развить свыше 40G в выделенном канале (Ethernet за 100G перешагнули в 2015 году в коммерческом использовании). Относительно текущей статьи, я выделю основной плюс сетей SDH - прописал для клиента конкретное количество ресурса, и клиент не сможет забрать из магистрального потока бОльшее количество ресурса, сервис клиента с точки зрения качества будет ровно таким, какой прописали в SLA контракта, исходя из параметров технологии, посредством чего этот канал и был предоставлен. То же самое касается и базовых станций - прописали 8 Е1 на базовую станцию, БС ограничена во всех ее трех (реже 4, 5, 6) секторах 16-ю мб/с. Подключили две БС каскадом на тех же 8 Е1, значит две БС будут делить между собой все те же 16 мб/с - все просто.
Все началось из Москвы. Как мне рассказывали старожилы, примерно в 2007 году, все крупные телеком операторы задумались о том - как включать базовые станции нового поколения - на тот момент 3G - все также через из SDH? Посчитав затраты на развертывание сетей 3G, стало ясно, что сеть SDH станет дороже, нежели чем RAN 3G. И на выручку пришла технология Ethernet, которую в то время боялись как огня - TCP/IP, пакетная передача данных, коммутаторы, маршрутизаторы, модель OSI - какие-то незнакомые слова и аббревиатуры. Опустим тендерные перипетии, но основными поставщиками Ethernet оборудования для телеком операторов РФ стали Huawei и Nokia - причем Huawei архитектурно предлагали L2, а Nokia с самого начала были Full MPLS оборудованием. Есть вкрапления Cisco, Juniper - но чаще это магистрали и мелкие филиалы.
С внедрением сетей с технологией Ethernet, практически сразу стал вопрос о емкости и распределении трафика между клиентскими включениями - если в SDH все понятно (сколько прописал, столько и заняли полосы), то с Ethernet ничего не понятно - порты 100/1000 мб/с, да есть шейперы, но а как их ставить, если через один Ethertnet порт работают несколько базовых станций с сервисами разных приоритетов - есть реал тайм трафик критичный к потерям (голос и сигнализация), есть дата трафик, который не столь критичен к потерям. В тоже время деление трафика на голос и дату происходит на уровне контроллера (RNC), а не на уровне ТС. И тут на авансцену выходит QoS - Quality of Service с политиками приоритезации трафика.
Работа по внедрению политик и настройке оборудования делится на две сущности - это административная работа и техническая. Первое - это создание сквозной политики приоритезации трафика для абсолютно всех сегментов сети, которые так или иначе участвуют в передаче данных. Это достаточно трудоемкий процесс, но тем не менее, очень важный и ответственный, ведь от ошибок политики будет зависеть качество того или иного сервиса. Для оператора связи важно понять - какой предоставляемый сервис является основным, какой вторичен, где и какие SLA могут быть выдержаны, какие не могут и т.д.
Приведу пример распределения типов сервисов для 3G с их метками DSCP/P-bit.
Эта табличка означает, что на контроллере (RNC) необходимо для исходящего трафика для голосовых и не голосовых типов сервисов указать определенную метку (dscp или p-bit или и то и другое одновременно), для того, чтобы транспортная сеть MBH обработала тот или иной тип сервиса согласно своим политикам приоритезации трафика. Если это высокий приоритет, то ТС пропускает пакет без буферизации в режиме обработки tail drop, если это не высокий приоритет, то пакеты буферизируется, создаются очереди, и если памяти порта устройства достаточно, то пакет не отбрасывается. Если памяти не достаточно или есть перегрузка на интерфейсе, то пакет отбросится (это явление называется QoS Drop), и все это регулируется механизмами WRR. Это отдельная и очень большая тема, расскажу в другой раз. Сейчас наглядно покажу как это выглядит в реальности.
На графиках видно, как распределяется трафик по очередям на одном интерфейсе (клиентском в сторону базовой станции) и в каких очередях есть потери. Согласно приведенной табличке выше, можно понять, какой тип сервиса дропится в той или иной очереди. Главное, что нет дропа в EF (очередь, которая обслуживает голосовой сервис и сигнализацию). Для не приоритетных очередей, которые обслуживают дата-трафик (AF1-4), дроп позволителен в определенной доле десятых процентов. Эти потери пакетов вызывают ретрансмиты, которые в свою очередь провоцируют сужение TCP окна, которое напрямую влияет на скорость скачивания данных. В данном конкретном случае QoS drop вызван небольшим буфером для очередей на устройстве (маршрутизаторе), который не может сгладить микроберсты трафика LTE - решается заменой оборудования. В более современных версиях данного оборудования возможно программное перераспределение памяти на порты, обслуживающие высоконагруженных клиентов, но в этом, к сожалению, только замена.
После принятия решения о внедрении политики приоритезации трафика, в дело вступают инженеры, которые занимаются конфигурацией оборудования. Пример буду приводить на оборудовании МЕН и РРЛ Huawei. Стоит упомянуть, что на оборудовании MEN Huawei есть несколько типов интерфейсов - NNI и UNI - сетевые и клиентские соответственно.
Настройка NNI интерфейса СХ600
interface GigabitEthernet1/0/1 | Настройка main интерфейса |
carrier up-hold-time 10000 | Задержка на перевод порта в активное состояние. Необходима для предотвращения дрожания интерфейса. Применяется в кольцевых топологиях. Не применяется при топологиях типа: цепь |
negotiation auto | negotiation необходим для быстрого обнаружения отказа в случае выхода из строя одного из двух волокон |
description XXXXXXXX | Описание порта (к какому соседнему устройства подключен) |
undo shutdown | |
set flow-stat interval 10 | указание периода сбора статистики |
mtu 9600 | Настройка MTU. Необходимо обратить особое внимание на значение MTU. Для NNI интерфейсов между СХ600 MTU=9600; для NNI интерфейсов к ATN MTU=9500. |
Настройка ip адреса из диапазона интерконнекта | |
isis enable 100 | Назначение номера ISIS процесса. Для main интерфейсов номер = 100; для саб-интерфейсов номер = номеру домена доступа |
isis circuit-type p2p | Указание типа ISIS интерфейса. Значение всегда p2p |
isis cost XXX | Команда указывается только при использовании скорости канала ниже скорости физического интерфейса. Значение cost вычисляется по формуле: cost=1000000/ полоса пропускания(в Мбит/с) . |
Например, при аренде канала 400Мбит/с при подключении через гигабитный порт: cost=1000000/400=2500 | |
ospf network-type p2p | Включение OSPF Area0 между агрегаторами (в случае использования RTN). network-type - значение всегда p2p |
| Значение cost (1-65535) вычисляется по формуле: OSPF cost= Bandwidth reference value (в мегабитах)/Interface bandwidth (в мегабитах). |
| Для типовых скоростей: |
| 100000/100000 = 1 (для 100G линка) |
| 100000/10000 = 10 (для 10G линка) |
| 100000/1000 = 100 (для 1G линка) |
| 100000/100 = 1000 (для 100М линка) |
| 100000/10 = 10000 (для 10М линка) |
| 100000/1 = 65535 (Максимальное значение OSPF cost) |
ospf enable 1 area 0.0.0.0 |
|
ospf cost 100 |
|
mpls | Включение MPLS |
mpls te |
|
mpls rsvp-te |
|
mpls rsvp-te hello |
|
mpls te link administrative group 111 | [Опционально]. Указание административной группы для интерфейса |
undo dcn | Отключение функции dcn. DCN может быть включена при проведении пусконаладочных работ |
trust upstream default | Включение полного доверия маркировке(включая CS6,CS7) |
port-queue be wfq weight 4 port-wred wred_be outbound | Настройка политики QoS порта. Значение шейпера EF может корректироваться в зависимости от профиля реального трафика. Базовое значение шейпера для EF трафика = 50% от полосы пропускания канала. |
port-queue af1 wfq weight 10 port-wred wred_af1 outbound |
|
port-queue af2 wfq weight 15 port-wred wred_af2 outbound |
|
port-queue af3 wfq weight 20 outbound |
|
port-queue af4 wfq weight 20 outbound |
|
port-queue ef pq shaping 5000 outbound |
|
clock priority 10 | Разрешить прием синхронизации. Указание приритета синхронизации |
clock synchronization enable | Включение протокола SyncE на интерфейсе |
Настройка UNI интерфейса СХ600
interface GigabitEthernet2/1/10.1001 | Настройка саб-интерфейса для передачи данных NodeB/eNodeB |
description | Описание саб-интерфейса (для чего используется) |
mtu 9600 | Настройка MTU |
vlan-type dot1q 1001 | Указание c-vlan |
loop-detect enable | Включение loop-detect |
loop-detect block 5 | |
loop-detect priority 1 | |
loop-detect trigger interface-down enable | |
l2 binding vsi xxx | Указание VSI |
mac-limit maximum 100 rate 0 | Ограничение количества изучаемых MAC-адресов |
trust upstream default | Привязка diffserve домена. Доверие маркировке DSCP |
statistic enable | Включение сбора статистики саб-интерфейса |
qos-profile mobile-in inbound | Применение профиля QoS без ограничения полосы пропускания. Может применяться профиль с ограничением полосы пропускания (в зависимости от политики QoS сети) |
qos-profile mobile-out outbound | |
Как видно из настроек, на сетевые и клиентские интерфейсы применены политики QoS с некоторой обработкой и доверием полю DSCP. Приведу пример настройки оборудования РРЛ Huawei
Как видно из настройки, указан тип доверия входящей маркировке - ip-dscp. Это означает, что РРЛ, подключенная к оборудованию МЕН будет доверять (не ремапить) входящему трафику со стороны оборудования МЕН и смотреть в поле DSCP для того, чтобы классифицировать трафик для дальнейшей обработки. На основании классификации и установленных политик внутри РРЛ, РРЛ примет решение, какой трафик она отбросит, в случае перегрузки в радио стволе. Т.е. на стыке двух разных типов оборудования - МЕН и РРЛ, должны быть одинаковые настройки с точки зрения маппинга и с точки зрения доверия - с двух сторон DSCP. Тогда в этом случае РРЛ корректно распознает трафик и корректно его обработает в случае перегрузок или иных ограничений.
Теперь рассмотрим ситуацию, когда инженер ошибся, и установил на стороне РРЛ доверие маркировке не DSCP, а P-Bit. РРЛ станет смотреть только в P-Bit, а оборудование МЕН не устанавливает в это поле никаких значений, т.к. нет соответствующей команды. По дефолту в этом поле нули, поэтому РРЛ весь трафик классифицирует как BE и обработает его с наименьшим приоритетом. В случае перегрузки пакеты будут дропиться в рандомном порядке и абсолютно все, не зависимо от того, голос это или дата трафик. Это приведет к потере голосовых фреймов и значительному искажению при разговоре, в худшем случае потере слов, колл-дропу (когда дропнется сигналка), не дозвонам и прочим "прелестям". Т.к. перегрузок на сети у всех операторов достаточно много, то соответствие сетей политикам приоритезации трафика - must have!!! Но, к сожалению, ни у одного оператора в РФ нет единой системы контроля за настройками на сети. Если худо бедно сверка параметров настройки QoS реализована и как-то выявляет проблемы с помощью комплексов, подобных Max Patrol, то на РРЛ эта проблема не решена никак. Дело в том, что каждый производитель РРЛ не предусмотрел единого механизма выгрузок конфиг файлов, унификации настройки параметров, что выливается в невозможность корректной проверки настроек. Чаще исправление конфигураций выполняется при решении конкретной задачи у конкретного абонента - есть проблемы с голосом, пошли проверять QoS по всему пути прохождения трафика, который прежде нужно выявить.
На этом все, пишите вопросы, отвечу на них с удовольствием.