1. Введение

Автоматические выключатели (АВ) — это основа безопасности любой электроустановки: от квартирного щитка до высоконагруженных стоек ЦОД. Их корректная работа защищает оборудование от повреждений, а людей — от рисков, связанных с перегрузкой и коротким замыканием.

Настоящее тестирование представляет интерес для широкого круга лиц, чья деятельность связана с выбором, проектированием или эксплуатацией низковольтных сетей:

• Для собственников жилья и мастеров, планирующих ремонт или замену электрощита — это наглядный пример того, почему «автоматы» с одинаковой маркировкой могут вести себя по-разному, и как этот разброс влияет на долговременную надежность домашней сети.
• Для инженеров-проектировщиков и монтажников — это практический сравнительный анализ, позволяющий принимать более обоснованные решения при подборе компонентов для коммерческих, промышленных объектов или телекоммуникационных шкафов, где важны температурные режимы и селективность защиты.
• Для высококвалифицированных инженеров, обслуживающих ЦОДы и ответственные системы — это демонстрация важности контроля входного качества даже стандартных компонентов, а также методология внутренней проверки, которую можно адаптировать под свои нужды.

Изначальной задачей, инициировавшей это тестирование, была необходимость выбора оптимальных компонентов для климатических шкафов собственного производства, используемых в крупных проектах. В процессе мы столкнулись с вопросом: насколько предсказуемо поведение АВ разных брендов в рамках одного стандарта? Полученные результаты и методика анализа оказались полезными и релевантными для всех перечисленных выше аудиторий.

Автоматические выключатели отличаются:

• Номинальной токовой уставкой, на которую они рассчитаны (в нашем тестировании используются АВ на 6А).
• Характеристикой срабатывания электромагнитного расцепителя. Она определяет, при какой кратности тока короткого замыкания произойдет отключение. Наибольшее распространение получили АВ с характеристиками:
  • B (превышение номинального тока в 3–5 раз);
  • C (превышение номинального тока в 5–10 раз);
  • D (превышение номинального тока в 10–20 раз).

Основное распространение имеют автоматические выключатели с характеристикой электромагнитного расцепителя «С», которые обеспечивают основную потребность.

Важное пояснение о характере проведённой работы

Данный отчёт представляет собой результаты внутреннего сравнительного тестирования, выполненного в рамках инициативы по углублению экспертизы в области применяемых электротехнических компонентов.

Важно отметить:

1. Работа не является официальными сертификационными или приёмочными испытаниями в соответствии с ГОСТ Р 50345-2010.
2. Тестирование проводилось на неповеренном серийном измерительном оборудовании в условиях, моделирующих нормальную эксплуатацию. Абсолютные значения измерений могут содержать инструментальную погрешность.
3. Методика имела упрощения (например, последовательное подключение образцов), что могло повлиять на тепловой режим и точность фиксации времени отключения.

Цель работы: выявить разброс эксплуатационных характеристик (температурный режим, время срабатывания) у различных моделей АВ, формально соответствующих одному стандарту, и выделить образцы, требующие повышенного внимания при выборе для ответственных применений. Задача — не вынесение окончательного вердикта о соответствии, а формирование инженерно-обоснованных гипотез для дальнейшего анализа.

2. Методология и условия тестирования

• Условия окружающей среды: температура воздуха +23±2°C.
• Расстояние между АВ: 50 мм.
• Корректировка тока: для приведения к стандартным условиям (+30°C) использован температурный коэффициент Kt = 1,03. Скорректированный номинальный ток: Iном.корр = 6 А × 1,03 = 6,18 А.

Оборудование:

• Тепловизор UNI-T UTi260B (фиксация температуры корпуса).
• Устройство для проверки электромагнитного расцепителя АВ «Сатурн-М».
• Клещи токоизмерительные СЕМ DT-3367.
• Нагрузочный стенд резистивный 10 кВт.
• Ювелирные весы.

Для всех отобранных автоматических выключателей оптимальной является температура эксплуатации +30°С. При нашей температуре +23°С необходимо ввести поправочный коэффициент. Расчёт тока нагрузки скорректированного производится по формуле:

Iном.корр = Iном · Kt,

где Kt — температурный коэффициент. Определяется по графику зависимости номинального тока от температуры среды (графики приведены в документации производителей: IEK, EKF, Legrand и т.д.). Согласно графикам, Kt = 1,03. Корректировка номинального тока выполнена по формуле: Iном.корр = 6 А × 1,03 = 6,18 А.

3. Порядок тестирования

1. Измерение массы АВ.
2. Тепловой расцепитель, этап 1: подача тока 1,13 × Iном.корр (6,99 А) в течение 60 минут (условное время нерасцепления). Фиксация температуры каждые 10 минут.
3. Тепловой расцепитель, этап 2: без перерыва плавное увеличение тока до 1,4 × Iном.корр (8,65 А) и фиксация времени до срабатывания.
    *Примечание: В ГОСТ Р 50345-2010 указано значение 1,45. В данном тесте использовано 1,4.*
4. Электромагнитный расцепитель: на холодных образцах определение минимального тока отключения в диапазоне (5–10) × Iном.корр (30,9 – 61,8 А).

4. Результаты и анализ

4.1. Сводные данные

Для удобства анализа ключевые результаты сведены в Таблицу 1. Полные данные по температуре представлены в Приложении А.

4.2. Графический анализ ключевых параметров

Рисунок 1. Динамика нагрева корпуса при токе 1,13·Iном (выборка моделей)

График подтверждает сильный разброс установившейся температуры: модели Easy 9 и S201 отличаются на ~31°C при одинаковой нагрузке. Все образцы выдержали часовую нагрузку без срабатывания. Максимальная температура корпуса варьировалась от 39,2°C (Easy 9) до 70,0°C (S201). Наименьший нагрев отмечен у моделей Easy 9, RX3 и Armat. Зависимость температуры от времени носит экспоненциальный характер с выходом на установившийся режим после 30–40 минут.

Здесь можно посмотреть на видеоролик процесса.

Рисунок 2. Время срабатывания при токе 1,4·Iном

Гистограмма визуализирует два аномальных результата: гиперчувствительность Yon MD63-1C6 и «вялое» срабатывание Systeme9, S201.

Рисунок 3. Процесс тестирования теплового расцепителя АВ

Посмотреть видео процесса.

4.3. Анализ выявленных отклонений

1. Тепловая защита: Yon MD63-1C6 сработал через ~20 секунд после увеличения тока до 1,4·Iном, что на порядок меньше ожидаемого времени (норма от 1 до 60 минут). Это может указывать на неверную калибровку биметаллической пластины или дефект в механизме.
2. Тепловая защита: City9 4,5kA имеет аномально малое время срабатывания (4 мин), что может указывать на смещение тепловой характеристики, возможно, в рамках допустимого разброса, но требующее проверки на селективность.
3. Электромагнитная защита: Образец ВА47-60М сработал при токе 27,5 А, что ниже минимального порога для характеристики «C» (30,9 А). Такое поведение повышает риск ложных срабатываний при пусковых токах некритичной нагрузки.
   Посмотреть видеоролик.
4. Пограничные значения: Ряд моделей (Systeme9, Armat, Yon MD63N) имеют порог срабатывания электромагнитного расцепителя вблизи нижней границы диапазона (38–39 А). При проектировании сетей с оборудованием, имеющим высокие пусковые токи, это требует дополнительного запаса.

5. Обсуждение и практические выводы

1. Масса и тепловой режим: Наблюдается корреляция между массой АВ и его конечной температурой при длительной нагрузке. Однако масса не является абсолютным критерием, так как на тепловой баланс также влияет конструкция дугогасительной камеры, материал контактов и внутренняя компоновка.

2. Разброс характеристик: Даже в рамках одного ценового сегмента наблюдается значительный разброс по ключевым параметрам. Разница в температуре нагрева на 15°C под одной и той же нагрузкой свидетельствует о различном качестве применяемых материалов и уровне технологического контроля.

3. Рекомендации по выбору:

• Для цепей с длительной нагрузкой, близкой к номинальной (например, освещение, розеточные группы), предпочтительны модели с более низким нагревом корпуса (Easy 9, RX3, Armat). Это снижает тепловую нагрузку на проводку и смежные компоненты в шкафу.
• Для защиты цепей с оборудованием, имеющим высокие пусковые токи, следует выбирать АВ с порогом срабатывания электромагнитного расцепителя в верхней части диапазона (50–60 А), такие как Easy 9, Dekraft, Averes.
• Образцы, показавшие значительные отклонения (Yon MD63-1C6, ВА47-60М), требуют особого внимания. Рекомендуется их выборочная проверка при закупке или проведение дополнительных тестов в аккредитованной лаборатории для подтверждения соответствия ГОСТ.
• Критерий «цена-качество»: На основании полученных данных, модели Legrand RX3 и Schneider Easy 9 демонстрируют оптимальное сочетание стабильных характеристик, умеренного нагрева и разумной стоимости (см. Таблицу 2, Приложение А). Для менее критичных применений с запасом по току могут рассматриваться модели Dekraft или Generica, показавшие приемлемые результаты при значительно более низкой цене.

       4. Аномалии и причины:

• Yon MD63-1C6 (сработал за 20 сек при 1,4·Iном): Крайне вероятно, что калибровочный винт отрегулирован с сильным избыточным предварительным натягом, что делает расцепитель гиперчувствительным. Биметаллу требуется минимальный нагрев, чтобы преодолеть зазор и отключить автомат.
• Systeme9, S201 (не отключились за 60 мин при 1,4·Iном): Обратная ситуация — недостаточный натяг или чрезмерный зазор. Биметалл изгибается, но этого усилия не хватает для срабатывания защёлки в нормативное время.
• ВА47-60М (низкий порог э/м расцепителя): Скорее всего, проблема связана с калибровкой соленоида (подгибкой пружины или изменением воздушного зазора).

6. Заключение

Проведённое сравнительное тестирование наглядно демонстрирует, что автоматические выключатели, формально соответствующие одному стандарту, могут существенно различаться по своим фактическим эксплуатационным характеристикам. Особенно важен этот разброс для применений, где критичны тепловые режимы или вероятность ложных срабатываний.

Окончательные выводы о соответствии конкретного изделия ГОСТ могут быть сделаны только по результатам испытаний в аккредитованной электролаборатории. Данная же работа служит практическим инструментом для формирования инженерной экспертизы, обоснованного выбора компонентов и определения направлений для более углублённого контроля качества.

Приложение А. Полные данные измерений массы, температуры и времени срабатывания

Таблица 2. Сравнительная таблица стоимости и массы

Рисунок 4. Процесс измерения массы АВ

Таблица 3. Температура АВ при токе 1,13·Iном

Таблица 4. Время срабатывания АВ при токе 1,4·Iном

Рисунок 5. Время срабатывания и температура АВ при токе 1,4·Iном

Приложение Б. Схематичное сравнение времятоковых характеристик (ВТХ) на основе данных тестирования

На основе полученных экспериментальных данных построена схематическая диаграмма, иллюстрирующая разброс времятоковых характеристик тестируемых автоматических выключателей относительно «идеальной» кривой для характеристики «C» согласно ГОСТ Р 50345-2010.

Рисунок 6. Сравнение время-токовых характеристик АВ

Описание графика:

Оси графика:

• Ось X (горизонтальная): Ток, выраженный в кратности к номинальному току (I/Iном). Логарифмический масштаб. Диапазон: от 1 до 20.
• Ось Y (вертикальная): Время срабатывания, секунды. Логарифмический масштаб. Диапазон: от 0,01 с до 10 000 с (≈2,78 часа).

Ключевые зоны и линии:

1. «Идеальная» ВТХ (ГОСТ, х-ка «C»): Пунктирная линия, обозначающая ожидаемые границы срабатывания для АВ.
2. Область теплового расцепителя (наклонная часть): Проходит между точками ~1,13·Iном (3600 с) и ~5·Iном (0,1–10 с).
3. Область электромагнитного расцепителя (вертикальная часть): Резкий обрыв вниз в диапазоне 5–10·Iном.
4. Зона нерасцепления: Область выше и левее линии ВТХ, где автомат не должен срабатывать.
5. Зона гарантированного расцепления: Область ниже и правее линии ВТХ.

*Внимание: Настоящая диаграмма является схематичной интерпретацией и построена на основе двух экспериментальных точек для теплового расцепителя (1,13·Iном и 1,4·Iном) и одной точки для электромагнитного. Она служит для визуального сравнения характера отклонений, а не для точного построения полной время-токовой характеристики (ВТХ), требующей снятия десятков точек на специализированном стенде.*

Нанесенные экспериментальные точки:

На график нанесены ключевые точки, полученные в ходе тестирования для трёх категорий моделей:

1. Стабильные модели:
 Schneider Easy 9 / Legrand RX3 (красные маркеры):

• Точка A1 (тепловой расцепитель): При 1,4·Iном (8,65 А) время срабатывания составило 41–43 минуты (2460–2580 с). Точка расположена в верхней части зоны расцепления, близко к «идеальной» кривой.
• Точка A2 (электромагнитный расцепитель): Срабатывание при ~9·Iном (56 А). Точка находится в верхней части диапазона 5–10·Iном.

2. Модели с отклонениями:
 Systeme9, S201 (завышенная уставка, жёлтые маркеры):

• Точка B1 (тепловой расцепитель): При 1,4·Iном время срабатывания >60 минут (>3600 с). Точка находится ВЫШЕ линии зоны нерасцепления, что указывает на возможную нечувствительность к перегрузке.
• Точка B2 (электромагнитный расцепитель): Срабатывание при ~6,2·Iном (38,5 А). Точка у нижней границы диапазона.

Yon MD63-1C6 (заниженная уставка, розовые маркеры):

• Точка C1 (тепловой расцепитель): При 1,4·Iном время срабатывания 20 секунд. Точка расположена НИЖЕ и ЛЕВЕЕ «идеальной» кривой, в зоне гарантированного расцепления, но слишком близко к началу, что свидетельствует о гиперчувствительности.
• Точка C2 (электромагнитный расцепитель): Срабатывание при ~6,5·Iном (40 А). Точка у нижней границы диапазона.

3. Модель с отклонением по э/м расцепителю:
 ВА47-60М (голубой маркер):

• Точка D (электромагнитный расцепитель): Срабатывание при ~4,5·Iном (27,5 А). Точка находится ЛЕВЕЕ диапазона 5–10·Iном, в зоне, предназначенной для тепловой защиты. Это указывает на высокий риск ложных отключений при кратковременных пусковых токах.

Выводы по графику:

Схема наглядно демонстрирует:

1. Существенный разброс характеристик: Фактические точки срабатывания разных моделей значительно удалены друг от друга при одном и том же токе (1,4·Iном).
2. Характер отклонений: Можно четко идентифицировать, является ли отклонение следствием смещения тепловой кривой (как у Systeme9, S201 и Yon MD63-1C6) или смещения уставки электромагнитного расцепителя (как у ВА47-60М).
3. Практическую значимость: Автоматы, чьи точки лежат вблизи «идеальной» кривой (стабильные модели), обеспечат более предсказуемую и селективную защиту. Модели с точками, выходящими за ожидаемые границы, могут привести к несвоевременному отключению (ложные срабатывания или, наоборот, отсутствие защиты).

Перспективы дальнейшей работы:

Анализ конструкции: вскрытие и сравнительный анализ внутренней конструкции (расположение элементов, измерение индуктивности катушки элетромагнитного расцепителя, строение дугогасящей камеры) образцов-лидеров и аутсайдеров. 

Посмотреть видео. 

Продукты в телеком-сфере редко рождаются из озарения. Чаще — из напряжения. Из несостыковок между тем, как рынок должен работать в презентациях, и тем, как он работает на самом деле. Из разговоров с клиентами, после которых остается неприятное чувство: вроде бы всё сделали правильно, но что‑то всё равно не складывается.

Эта статья — не мотивация и не инструкция. Это рассказ о том, как в реальности создаются продукты в сложных, конкурентных и технологически насыщенных рынках: видеонаблюдение, SIP‑телефония, IP‑домофония. 

Рынках, где почти всё уже придумано, но далеко не всё — понято.

 Сквозная логика создания продукта

Любой живой продукт — независимо от рынка, технологий и масштаба компании — проходит одну и ту же цепочку. Она может называться по‑разному, обрастать сложными терминами, но по сути всегда сводится к следующему:

Наблюдение → гипотеза → ограничение → проверка → отказ или усиление

Это не процесс ради методологии. Это способ не сойти с ума. 

Наблюдение — это момент честности с реальностью. 

Гипотеза — момент риска. 

Ограничение — момент взросления. 

Проверка — момент столкновения с рынком. 

Отказ или усиление — момент ответственности.

Компании, которые ломаются, ломаются почти всегда в одном из этих узлов: либо перескакивают наблюдение, либо боятся отказа, либо игнорируют ограничения.

Держите эту цепочку в голове всегда. Всё, что вы делаете с продуктом, — это движение по ней, иногда вперед, иногда назад. Не бойтесь возвращаться на пройденные этапы.

I. Наблюдение. Продукт начинается далеко не с идеи

Идеи переоценены. На зрелых рынках идея сама по себе почти ничего не стоит. Стоит умение увидеть повторяемую проблему и не отвернуться от неё, даже если она неудобна.

Хорошие продукты начинаются с наблюдений: как реально устанавливают камеры, где инженеры тратят время впустую, в каких местах системы ломаются не технически, а организационно. 

Это не красивые инсайты — это скучные, повторяющиеся детали.

Многие компании пропускают этот этап. Они начинают сразу с формулировки решения, потому что решение — это комфортно. Оно даёт ощущение контроля. Наблюдение — нет.

Важно: если вы не можете описать проблему без упоминания вашего будущего продукта, вы ещё не на старте.

II. Гипотеза: момент, где рождается самообман

Как только наблюдение превращается в гипотезу, появляется риск. Гипотеза — это уже интерпретация. Здесь легко начать видеть не рынок, а подтверждение собственных ожиданий. Классическая ошибка — сформулировать гипотезу слишком широко: «рынку нужно более надежное видеонаблюдение». Это не гипотеза, а банальность.

Рабочая гипотеза всегда конкретна: кто, в каком контексте, какую проблему пытается решить и какой ценой. 

Как понять, что гипотеза жизнеспособна? Рынок либо готов тратить деньги, либо время. Если не готов ни к тому, ни к другому — гипотеза мертва.

III. Ограничения — не враг продукту, а его форма

В какой-то момент любой продукт упирается в границы. Это может быть технология, экономика, регуляторика, ресурсы команды или просто здравый смысл. Инстинктивная реакция — воспринимать ограничения как помеху, как то, что мешает «сделать по‑настоящему хороший продукт». На самом деле всё наоборот. Ограничения — это не внешнее давление. Это форма, в которую отливается продукт. Без формы он остается бледным и хаотичным набором возможностей.

В телекоме это особенно заметно. Поддержка стандартов, требования безопасности, совместимость с существующей инфраструктурой, ожидания интеграторов — всё это создаёт ощущение, что продукту не дают «развернуться». Но именно в этих условиях и проявляется зрелость продуктового мышления.

История зрелых компаний это подтверждает. Apple годами сознательно ограничивал кастомизацию устройств и экосистемы. Amazon на старте ограничивал функциональность ради скорости и надёжности. Эти решения часто вызывали критику, но именно они позволяли сохранить фокус и масштабироваться.

В видеонаблюдении ограничения выглядят менее романтично, но работают так же. Когда производитель пытается поддержать все протоколы, все сценарии, все требования сразу — продукт становится тяжелым, дорогим в сопровождении и плохо объяснимым. Интеграторы начинают «обходить» функциональность, клиенты — использовать систему на 20% возможностей, а поддержка — тонуть в нестандартных кейсах. 

С какими проблемами мы сталкиваемся?

Самая частая — давление «расширить рамки»:

Продажи будут настаивать на снижении цен и дополнительном функционале.

Партнёры — на специфических сценариях. 

Внутри команды всегда найдется аргумент: «Технически мы можем». И это правда. Почти всегда можем.

Вторая проблема — страх. Ограничение воспринимается как риск потерять сделку или сегмент. Кажется, что если сказать «нет», клиент уйдёт. Иногда это действительно так. Но гораздо чаще клиент уходит позже — когда продукт оказывается слишком сложным или нестабильным

Историческая справка. В линейке видеокамер OMNY есть модель серии OMNY PRO UB, которая может похвастаться самым богатым набором характеристик и качеств, и при этом очень приятной ценовой политикой. Но в то же время она отталкивала клиентов своей потенциальной сложностью. В качестве выхода из данной ситуации, было решено демонстрировать данную модель как устройство для решения одной конкретной задачи, предварительно очень тщательно изучив клиента и предлагая лишь целевой для него функционал.

Важно:

Ограничение — это осознанный выбор, а не вынужденная мера. Каждый раз, когда вы вводите границу, вы говорите рынку: вот где мы сильны, а вот где — нет. Это делает продукт честным.

Хороший вопрос, который стоит задавать себе регулярно: это ограничение про защиту ценности или про нашу лень? 

Если первое — его нужно отстаивать. Если второе — его нужно пересматривать.

Как работать с возражениями?

Возражения против ограничений почти всегда формулируются одинаково:

• «Но конкурент это поддерживает».
• «Клиент этого ожидает».
• «Без этого нас не возьмут в проект».

Рабочая позиция здесь — не оправдываться, а переводить разговор в плоскость последствий. Что произойдет с продуктом через год? С поддержкой? С обучением партнеров? С обновлениями?

Во многих случаях выясняется, что расширение рамок решает краткосрочную задачу, но создает долгосрочную проблему. И наоборот — жесткое ограничение сначала вызывает сопротивление, но со временем становится конкурентным преимуществом.

Так, например, линейка продуктов OMNY проходит регулярную “Сезонную уборку”: 

• Модельный ряд балансируется, невостребованные на рынке проектные модели выводятся из ассортимента.
• Генерируются новые задания на завод-производитель для создания более лучшего продукта для текущих задач и потребностей рынка.
• Оптимизируются цены на текущую регулярную(канальную) линейку.

Как понять, что ограничения выбраны правильно?

Правильные ограничения:

• упрощают продукт, а не усложняют его;
• делают ценность яснее, а позиционирование — короче;
• снижают количество нестандартных кейсов;
• помогают команде быстрее принимать решения.

Если после введения ограничения продукт становится легче объяснять и поддерживать — вы движетесь в правильном направлении.

IV. Делать как все — рационально. Делать осознанно — сложно

На зрелых рынках почти всё видно заранее. Есть лидеры, есть догоняющие, есть устоявшиеся сценарии: какие функции считаются обязательными, какие характеристики попадают в презентации, какие слова используют коммерсанты.

Делать «как все» в таком контексте — не признак слабости. Это естественная и во многих случаях оправданная стратегия выживания.

Важно не переборщить с подходом «как все», в противном случае продукт ждет печальная судьба - утонуть в серой массе из догоняющих. 

Особенно это заметно в видеонаблюдении. Большинство производителей выпускают камеры с похожими характеристиками: разрешение, чувствительность, WDR, базовая аналитика, стандартизация протоколов. Рынок к этому привык. Если чего‑то из этого нет — продукт даже не попадает в шорт‑лист.

Компания Dahua долгое время строила именно такую стратегию: не изобретать рынок заново, а системно закрывать ожидания. Широкая линейка, понятное позиционирование, быстрый вывод моделей, агрессивная работа с каналом. 

Это был не творческий порыв, а холодный расчёт — и он работал.

Проблема начинается позже. Когда рынок насыщается, различия стираются, а продукты становятся взаимозаменяемыми и обезличенными. В этот момент стратегия «делать как все» перестает быть защитой и превращается в ловушку. Любое отставание — по цене, по логистике, по срокам поставки — сразу становится критичным.

И здесь появляется соблазн «пойти своим путём». Добавить необычную аналитику, нестандартный форм‑фактор, сложную архитектуру. Часто это подаётся как попытка выделиться. Но рынок не награждает за уникальность саму по себе.

Рассуждение:

Если посмотреть на практики мировых лидеров, становится видно: они редко выбирали путь «мы будем не как все». Они выбирали путь радикального упрощения ключевого сценария. Apple не делал больше функций — он убирал лишние. Amazon не добавлял возможностей — он сокращал путь от желания до покупки. Netflix не улучшал качество видеопроката — он убирал ожидание.

В видеонаблюдении это может выглядеть менее эффектно, но логика та же. Иногда выигрыш даёт не новая аналитика, а понятная модель лицензирования. Не уникальный сенсор, а предсказуемое поведение системы при сбоях. Не максимальный набор настроек, а стабильно работающее ПО.

Важно:

Выбор «как все» или «по‑своему» — это не идеологический вопрос. Это вопрос зрелости. Делать как все имеет смысл, пока вы понимаете, какую часть ценности вы берёте на себя лучше рынка. Идти своим путем имеет смысл только тогда, когда вы готовы отказаться от части ожиданий и объяснить почему.

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

Как понять, что путь выбран правильно?

Выбор начинает работать, когда:

• продукт можно описать одной фразой без уточнений;
• продажи перестают объяснять, чем вы отличаетесь, и начинают объяснять, зачем вы нужны;
• клиенты сравнивают вас не по списку характеристик, а по ощущению надежности и понятности.

Если для объяснения ценности требуется длинная презентация — вы, скорее всего, всё ещё «как все», но без честного признания этого.

Почему клиенты выбирают OMNY?

На этот вопрос можно ответить по разному, коротко или подробно. Можно сказать что им просто удобно брать всё в одном месте(шкафы, кабель, камеры, коммутаторы, ТВ-Приставки), но прямой, понятный и честный ответ будет следующим: 

• Камеры OMNY - это идеальный вариант для крупного телекома, т.к. позволяет закупать большие объемы с понятным и удобным сроком поставки, и возможностью оперативной интеграции и проведения пилотных проектов.
• Мы способны выполнить кастомизацию устройств даже под небольшие объемы партий.
• Малые и суб-операторы не могут позволить себе закупать партии по 10000 единиц. Это автоматически превратит остатки нового оборудования в неликвиды.
• Гибкость бренда (уникальные характеристики, дилерские договоры, ценовая политика, стабильность в работе ПО).

При этом ассортимент бренда OMNY не раздувается до нескольких сотен моделей, отличающихся друг от друга незначительными характеристиками. Как удалось этого достичь? Все достаточно просто.

 Мы поставляем оборудование нескольких категорий, чтобы конкурировать на рынке: 

1. Канальное оборудование. Оборудование созданное лишь для одной задачи: Показывать хорошо, за хорошие деньги. Такое оборудование всегда в наличии, и может закрыть 90% потребностей клиента. Стандартизация, унификация и поддержание лояльной ценовой политики - основа канального оборудования.
2. Проектное оборудование. Серьезное оборудование, покупаемое клиентами как правило небольшими объемами. Целей и задач у таких устройств великое множество, от распознавания лиц до фиксации свободных мест на публичных парковках. На такое оборудование выполняется регистрация проекта, для избежания демпинга цен. Например как камера линейки OMNY PRO UB
3. Оборудование со специфичной сертификацией. Достаточно часто можно услышать от клиентов потребность в оборудовании со статусом СТ-1 или сертификацией по 969-ФЗ. Такие проекты индивидуально прорабатываются с менеджерами и полностью считается вся экономика проекта.

Таким образом модель линейки OMNY PRO UB смогла сместить конкурентов в проекте “Безопасные дороги”, успешно пройти отбор, и теперь она выступает как оконечное устройство с технологией распознавания номеров(LPR). Добиться этого помог индивидуальный подход к клиенту, и сокращение количества функциональных возможностей устройства до одного единственного сценария.

V. Ценность важнее уникальности

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

Рынок, к сожалению, к этому равнодушен.

Для клиента уникальность сама по себе не имеет ценности. Она начинает что‑то значить только тогда, когда упрощает жизнь, снижает риски или экономит ресурсы. Всё остальное — шум.

На рынке видеонаблюдения это видно особенно хорошо. За последние годы появилось множество продуктов с «уникальной» видеоаналитикой, нестандартными алгоритмами, экзотическими сценариями. На демо они выглядели впечатляюще. В реальных проектах — почти не использовались. Причина проста: ценность этих возможностей не перевешивала сложность внедрения и эксплуатации.

Как мы создаем свою уникальность?

На примере линейки OMNY, можно заметить, что уникальные особенности вводятся не огромным объемом сразу, а постепенно и размеренно. Делается это для того, чтобы клиенты проходили стадию адаптации к изменениям в щадящем режиме и могли поучаствовать в развитии. 

В данном сценарии это позволяет просматривать рынок свыше и прогнозировать изменения, и вовремя быть готовыми к ним. Например, как возможность сервиса OMNYVideo консолидировать в себя устройства сторонних производителей, для повышения собственной абонентской базы в условиях “санкционных побегов” китайских производителей из бизнеса в РФ.

Так же и в остальных сегментах, таких как:

• Интеграция в сервис облачного видеонаблюдения ****Video с поставкой кастомизированного оборудования по требованиям заказчика
• Организация подсчета посетителей в сети цифровых гипермаркетов.
• Поставка видеокамер для ПВЗ.

Все эти проекты стали возможны и успешны благодаря двум качествам: Вовлеченность команды и лояльность к изменениям.

Где уникальность становится ловушкой?

Уникальность опасна в трех случаях. Первый — когда она не встроена в основной сценарий использования. Если функция есть, но о ней нужно специально помнить, она почти всегда будет игнорироваться.

Второй — когда уникальность требует отдельного обучения, настройки или поддержки. В B2B‑рынках это мгновенно увеличивает стоимость владения и снижает готовность интеграторов работать с продуктом.

Третий — когда уникальность используется как оправдание отсутствия базовой ценности: стабильности, предсказуемости, понятной логики поведения системы.

Важно:

Прежде чем гордиться уникальностью, задайте себе простой вопрос: если эту функцию убрать, клиент расстроится или вздохнёт с облегчением? Ответ почти всегда честный.

Зрелые продуктовые команды сознательно ставят ценность выше новизны. Они готовы отказаться от «вау‑эффекта» ради понятного и повторяемого результата.

Уникальность, которая работает

Рабочая уникальность редко выглядит как революция. Чаще это:

• понятная модель лицензирования там, где рынок запутан;
• предсказуемое поведение системы при сбоях;
• четкие границы ответственности между продуктом и интегратором;
• документация, по которой действительно можно работать;
• безупречно работающее ПО.

Такая уникальность редко попадает в маркетинговые лозунги, но именно она формирует доверие.

Как понять, что ценность действительно есть

Ценность проявляется не в словах, а в поведении рынка. Когда продукт:

• рекомендуют без дополнительных стимулов;
• используют шире, чем планировали изначально;
• защищают внутри организации клиента.

Если клиент готов объяснять ваш продукт своему руководству — вы создали ценность.
 

VI. Экономика как последний арбитр

Экономика — это момент, когда продукт перестает быть предметом дискуссий и становится предметом ответственности. До этого можно спорить о видении, стратегии, уникальности и рынке. Экономика же задаёт вопрос без эмоций: сколько стоит эта идея и кто за нее заплатит?

В телекоме особенно легко обмануть себя. Железо можно удешевить объемами, разработку — распределить по времени, поддержку — недооценить. 

На бумаге почти любой продукт можно заставить «сходиться». В реальности экономика вскрывает всё то, что было аккуратно спрятано под формулировкой «потом разберёмся».

Где чаще всего ломается логика?

Первое — игнорирование полной стоимости владения. Камера, платформа или домофон редко умирают из‑за себестоимости. Они умирают из‑за поддержки, обновлений, интеграций, обучения партнёров, сертификаций и кастомных кейсов, которые никто не закладывал.

Второе — вера в масштабирование как универсальное спасение. «Сейчас маржа низкая, но объёмы всё исправят» — опасная мысль. Масштабирование усиливает не только прибыль, но и ошибки. 

При этом не стоит забывать, что крупный оператор в основе своей закупает большие объемы для реализации своих потребностей, но в это же время жизненный цикл устройств становится больше, а потребность в оборудовании уменьшается. Так например, Телеком-компании с годами уменьшают количество закупаемого оборудования из за снижения объемов подключения новых абонентов и использования восстановленного оборудования(после реферба).

Третье — ставка на одного крупного клиента или сегмент. Экономика, завязанная на исключениях - не масштабируется. 

Основной проблемой данного подхода является самовнушение, что данный клиент с нами навсегда, или этих 100 клиентов нам будет достаточно для выполнения текущих плановых показателей. В случае оттока 20 клиентов при 100 ключевых, это снижение клиентской базы на 20%. Для любого бизнеса это катастрофа. 

Напутствие

Смотрите на экономику как на форму честного разговора с самим собой. Если цифры вызывают дискомфорт — это сигнал, а не помеха.

Полезный вопрос: что должно пойти идеально, чтобы эта модель заработала? Если ответов слишком много — модель хрупкая.

Предположим, себестоимость видеокамеры составляет 40$, с учетом доставки и растаможки в РФ. 

Если мы инвестируем в закупку камер с капитальными затратами под 16,5% годовых, это означает, что деньги «работают» и стоят дополнительных 16,5% затрат за год, если мы не продаём товар сразу.

Стоимость денег за год на единицу:

40 $ × 16,5 % = 6,60 $

Итого учет стоимости денег повышает стоимость каждой камеры до:

40 $ (база) + 6,60 $ (финансовые затраты) = 26,60 $ фактическая затратность

Помимо закупки, есть логистика, маркетинг, склад, сертификация, гарантийный фонд, возвраты. Обычно это оценивается как 10–30% от себестоимости, но может быть и выше в зависимости от объёма и сервиса. Примем условно 15%

Где N - количество к закупу.

40 $ × 15% × N = 6 $ × N

 Итого ≈ (40 + 6,60 + 6) × N ≈ 52,60 $ × N

 Основной вопрос в заключении данной формулы, кто будет это покупать? И в каких объемах?

Как понять, что экономика здорова?

Здоровая экономика продукта:

• выдерживает снижение цены; например OMNY;
• не рушится при росте поддержки, хватает оборотных средств;
• не держится на одном клиенте или канале;
• позволяет принимать решения без героизма, чтобы не пришлось для сохранения рабочих мест продавать остатки в минус.

Если для выживания продукта постоянно требуются исключительные усилия — проблема не в рынке.

VII. Запуск — момент истины

Запуск продукта часто воспринимается как финал. В реальности, это начало самой сложной части работы. Всё, что раньше обсуждалось теоретически, начинает проверяться практикой — иногда довольно болезненно.

Рынок редко реагирует так, как ожидают внутри компании. Продажи задают неудобные вопросы. Интеграторы используют продукт иначе, чем предполагалось. Клиенты находят сценарии, о которых никто не думал.

С какими проблемами мы сталкиваемся?

Первая — разрыв ожиданий. То, что казалось очевидным в презентациях, оказывается неочевидным в реальной установке или эксплуатации.

Вторая — неподготовленность экосистемы. Продукт может быть готов технически, но не готов организационно: продажи не понимают, как его продавать, поддержка — как сопровождать, партнёры — как внедрять.

Третья — эмоциональная реакция команды. Критика воспринимается как атака, а не как данные.

Напутствие

Запуск — это не момент защиты продукта, а момент его слушания. Чем быстрее команда перестает оправдываться, тем быстрее продукт начинает развиваться.

Как работать с первыми отказами?

Отказы после запуска — это не провал, а информация. Их важно фиксировать, группировать и проверять на повторяемость. Единичные случаи не определяют судьбу продукта. Повторяющиеся — определяют.

Полезная практика — разделять отказы на те, что связаны с ценностью, и те, что связаны с исполнением. Это разные задачи и разные решения.

Как понять, что продукт начал жить?

Признак жизни продукта — не рост продаж, а появление контекста. Когда клиенты начинают использовать продукт в сценариях, которые вы не закладывали, спорить о нём внутри своих организаций, возвращаться с вопросами и предложениями.

В этот момент продукт перестает быть вашим маленьким чадом. И это хороший знак.

VIII. Грехи

Грехи продуктовой работы редко выглядят как ошибки. Чаще всего они выглядят как рациональные объяснения, произнесённые уверенным голосом на совещании. Именно поэтому они так опасны.

Грех первый. Делать «чуть лучше, чем у конкурентов»

Это самый распространённый и самый бесполезный грех. Продукт, который «чуть лучше», требует столько же усилий, сколько продукт, который радикально проще или понятнее, но не дает рынку причины менять привычки.

Рынок видеонаблюдения завален примерами: +1 мегапиксель, +1 кодек, +1 аналитика. Клиент кивает, но покупает то, что он уже знает.

Напутствие: если отличие нельзя объяснить за одно предложение — его не существует.

Грех второй. Слушать всех одинаково

Продажи, поддержка, интеграторы, ключевые клиенты — все говорят разное и все уверены в своей правоте. Проблема начинается, когда продуктолог пытается угодить всем.

В итоге, продукт превращается в компромисс без характера.

Напутствие: слушать нужно всех, но следовать — только выбранной стратегии и целевой аудитории.

Грех третий. Путать запросы и причины

Клиенты часто просят не то, что им нужно, а то, что они умеют сформулировать. Просьба «добавьте функцию», почти всегда маскирует проблему процесса или сценария.

Напутствие: всегда спрашивайте «зачем?» и «что будет, если этого не сделать?».

Грех четвертый. Бояться убивать

Функции, продукты и идеи редко умирают сами. Их держат из страха признать ошибку или из уважения к вложенным усилиям.

Напутствие: отказ — это не поражение, а форма управления портфелем.

IX. Как не сойти с ума

Работа с продуктом — это постоянное напряжение между ожиданиями и реальностью. Давление идет со всех сторон: рынок требует одного, бизнес — другого, разработка — третьего.

Попытка быть удобным для всех приводит к выгоранию и плохим решениям.

Несколько практических опор

Во-первых, опирайтесь на данные, а не на громкость голоса. Эмоции заразительны, цифры — отрезвляют.

Во-вторых, фиксируйте решения письменно. Это снижает хаос и возвращает разговор к сути.

В-третьих, принимайте, что неопределенность — не временное состояние, а нормальный фон работы.

Напутствие

Мы не обязаны знать все, мы обязаны задавать правильные вопросы и вовремя принимать решения.

Если вы всё время чувствуете себя некомфортно — это не значит, что вы плохо работаете. Скорее всего, вы работаете правильно. 

Финал. Непреклонная воля

Создание продукта — это не вдохновение и не набор инструментов. Это последовательность выборов, каждый из которых отсекает альтернативы.

Хороший продукт всегда результат отказов:

• от лишних функций,
• от неподходящих клиентов,
• от удобных, но неверных решений.

Мировые лидеры отличаются не тем, что знают больше, а тем, что реже меняют направление без причины. Они наблюдают, формулируют гипотезы, вводят ограничения, проверяют и либо усиливают выбранный путь, либо отказываются от него.

Наблюдение → гипотеза → ограничение → проверка → отказ или усиление.

Это не цикл стартапа. Это цикл зрелого продукта.

Если после прочтения этой статьи стало чуть тяжелее — значит, текст сработал. Продукт — это всегда нагрузка. На мышление, на характер, на волю.

Но если вы готовы её нести — у вас есть шанс создать не просто устройство, а продукт, который переживёт презентации, бюджеты и смену стратегий.

И именно такие продукты остаются на рынке.

Арсений Кононенко,
менеджер по продукту,
отдел видеонаблюдения и SIP-систем компании НАГ.

В предыдущих статьях нам удалось разобраться:

Что такое видеоаналитика и зачем она нужна?

На каких платформах работает аналитика и как она обучается?

В этом материале мы разберем, какие ошибки допускают монтажники при выборе того или иного оборудования, его монтаже и настройке, а также разберемся, “как делать хорошо, а плохо не делать”.

Типовые проблемы при вводе аналитики в эксплуатацию (Советы по монтажу, разбор ошибок “1 камера на 99 аналитик”)

Главная мысль, которую хочу донести в данном разделе - несмотря на то, насколько “крутое” железо стоит на объекте, последние версии нейросетей и огромный бюджет, аналитика не будет работать, если камеры выбраны или установлены неправильно. И далее мы обсудим самые типичные проблемы, с которыми сталкиваются монтажники при проектировании объектов:

1. Попытка закрыть несколько задач с помощью одной камеры

Важно понимать, что реализация проекта по видеонаблюдению - это выбор оборудования для решения задачи, а не подгонка задачи под закупленное оборудование.

Например, существует две конкретные задачи:

Необходимо реализовать обзорное видеонаблюдение за площадкой.

Необходимо распознавать номера автомобилей, которые проезжают на этом же участке, либо лица людей.

Казалось-бы, все просто: ставим одну крутую камеру таким образом, чтобы и площадка просматривалась, и номера можно было увидеть, но…    

Если камеру установили для общего видеонаблюдения за территорией (особенно, если нужно обозревать большую площадь) - она вряд-ли сможет идентифицировать человека или распознать номер автомобиля.

Чисто технически, можно установить камеру большого разрешения (от 8мп и более), и попытаться закрыть несколько задач одновременно, только обратной стороной такого решения станет цена камеры, ее огромный битрейт и, как следствие, огромный размер архива.

Данная проблема особо остро ощущается в частном секторе, когда условный заказчик хочет относительно простую, но обязательно поворотную камеру для слежки за дачным участком. А как иначе, ведь PTZ делает “вжжж-вжжж”! Эйфория от приобретения заканчивается после первых десяти поворотов камерой, либо после кражи имущества, пока камера была повернута в другую сторону. При этом, за цену вменяемой PTZ можно купить с десяток камер попроще и установить их на все точки интереса, даже с некоторым перекрытием поля обзора для защиты от вандализма.

Поэтому самым логичным решением из сложившейся ситуации станет использование разных устройств под свои задачи. Для обзора за территорией - камеры с широким объективом, а для считывания номеров, распознавания лиц - камеры, подходящие под конкретные условия монтажа (моторизированный объектив и тд).

2. Использование камер с низким разрешением

Думаю, у каждого монтажника или инженера были ситуации, когда сотрудник охраны спрашивает: “У нас в 100500 метрах от ближайшей камеры остановилась машина какая-то, можно приблизить и посмотреть, что за номер у машины? Я в кино такое видел!”, при этом в архиве эта самая “машина” выглядит как 8 пикселей.

Но вот живем мы, к сожалению, не в кино, и даже не в сказке.

Для аналитик ситуация точно так же применима. Чем выше разрешение, тем больше данных камера предоставит для анализа, и тем выше будет % правильного распознавания.

Можете сказать: “Витя, мы тебя услышали, уже заказали вагон камер с Озона/Алиэкспресса за 5000 рублей и с разрешением 40 Мп, будем смотреть на всю котлету!”, но…

Но при этом стоит понимать, что камеру с 40 мегапикселями, поворотным механизмом, Wifi и LTE нельзя купить на маркетплейсах за 5 тысяч рублей. В лучшем случае - это будет камера с N матрицами и независимыми объективами. А что, логика в этом, бесспорно, есть, ведь если суммировать их все - как раз получится нужное разрешение.

4+4+4=12. А что, звучит логично...

Хотя и тут есть нюансы. Например, матрицы могут быть совсем не на 4 мегапикселя, а всего на два. При этом финальное изображение прогоняется через апскеллеры, и выглядит эта картинка еще хуже.

Схожая проблема может быть и с “именитыми” производителями камер, например - 8мп камера за 5000 рублей явно не будет иметь хорошую светочувствительную матрицу с 30 кадрами в секунду.

Если быть кратким - там, где требуется высокая детализация (например, распознавание лиц) - ставим дорогие камеры с хорошими матрицами, в идеале с моторизированным объективом, высокой светочувствительностью, опционально можно установить камеры с увеличенным количеством FPS, если движение очень интенсивное.

При этом, стараемся соблюдать баланс, и там, где территория менее ответственная (не нужно вглядываться в мелкие детали, а лишь фиксировать наличие/отсутствие людей и транспорта), можно сэкономить, причем неплохо: для закрытия задачи подобного рода хватит и 2 Мп камеры, желательно, с аппаратным WDR. Ну и учитывайте, что широкоугольный объектив даст больший угол обзора, но при этом меньше деталей.

Правда, даже крутая камера не факт, что справится с поставленной задачей, о чем далее.

3. Неправильная установка камер видеонаблюдения

В вступлении я написал, какой бы крутой аналитика не была, она не сможет адекватно работать, если камера установлена неправильно.

Существуют конкретные правила выбора и монтажа камер видеонаблюдения, предназначенных для работы в тандеме с аналитикой, и ниже я перечислю самые популярные из них.

а. Обнаружение и распознавание лиц

Пожалуй, это одна из самых популярных аналитик, применяющихся в наше время, которую, к сожалению, не умеют “готовить”.

Про то, как работает программная составляющая распознавания лиц написана крайне занятная статья на всеми любимом Хабре, и я готов с Вами ею поделиться.

Если приходилось слышать фразу: “Ну как же так, я купил крутую камеру, с моторизированным объективом, купил супер-ультра-аналитику, а она мне людей не распознает, либо делает это с ошибками!”, то дальнейший материал будет для Вас полезен.

На самом деле, % успешного распознавания лица, или же его детекция, зависит от трех конкретных составляющих:

• Используется подходящее оборудование.
• Модуль аналитики в камере или на сервере работает корректно.
• Камера установлена правильно.

И если с первыми двумя пунктами все более-менее ясно (используем камеры большого разрешения с регулируемой диафрагмой, в идеале с моторизированным объективом, включили аналитику, настроили чувствительность детектора, выдержку и тд), то с третьим пунктом у монтажников бывают большие проблемы.

Если быть достаточно кратким, то существуют конкретные требования к установке камер:

В идеале, человек должен идти прямо на камеру, при этом смотреть хотя бы в ее сторону. Поэтому, хороший вариант расположения камеры - коридоры и проходы.

Угол наклона камеры не должен превышать 10-15 градусов. Лучшим вариантом монтажа будет установка камеры была примерно на уровне лица человека.

Лицо должно быть в кадре полностью. Половина, четверть - не катит, оно просто не распознается (хотя может быть задетектировано). Также, на лицо в кадре должно приходиться не менее 160 пикселей. Понятное дело, чем больше - тем лучше.

Лицо должно быть в кадре достаточное для аналитики время. В среднем, это порядка 2-3 секунд. Это необходимо, чтобы система аналитики могла выбрать из всех сделанных кадров тот, в котором лицо видно лучше всего. 

Важно - освещение в кадре должно быть равномерным (порядка 150 люкс), а источники света не должны смотреть в кадр (либо светить из-за спины человека). Понятное дело, не нужны мегаватты света, иначе при анализе все люди будут щуриться.

Допустимые вертикальные углы установки камеры для распознавания лиц

Допустимые горизонтальные углы установки камеры для распознавания лиц

Хотя, даже правильная установка камер не даст 100% распознавания.

Вы можете возразить: “Как так, Виктор?! Вы же говорили, обещали…”

К сожалению, ни одна аналитика не является безошибочной (а ведь иногда даже люди не узнают знакомых на улице), правда унывать тоже не стоит. Ее процент ложных срабатываний весьма низок.

Давайте немного углубимся в то, какое распознавание лиц существует?

Если говорить про самые распространенные методы, то их всего два:

• 2D распознавание лиц
• 3D распознавание лиц

Конечно, можно сказать: “2д в сердце, 3д не нужны!”, но в нашем случае это не так работает). Я предлагаю рассмотреть плюсы и минусы 2D и 3D распознавания лиц (да, на камерах, регистраторах и серверах все работает +- одинаково).

2D в названии означает, что данная аналитика работает с плоским изображением. Соответственно, для реализации подобного метода анализа можно использовать обычные камеры систем видеонаблюдения, главное, чтобы они были установлены корректно.

Плюсы у данного метода весьма весомые:

• Возможность использовать уже установленный парк камер (в случае, если используется серверная аналитика)
• Стоимость камер с уже “вшитым” 2D распознаванием лиц значительно меньше, чем у камер с 3D распознаванием.
• Так как данный метод распознавания крайне популярен, существуют готовые базы данных, а сам алгоритм активно оптимизируется и совершенствуется разработчиками.

Но также у данного метода есть и существенный недостаток:

Процент ложных срабатываний (FAR и FRR) больше, чем у 3D распознавания лиц.

Пожалуй, распишу вкратце, как работает 3D распознавание лиц.

Данный метод опирается на реконструированные модели лиц. Звучит уже сложно, не так-ли? А ведь мы еще не затрагивали “механику” добавления новых лиц в базу посредством сканирования…

iDS-2CD8426G0/F-I - интеллектуальная камера со встроенным распознаванием лиц

На примере выше можно увидеть, что анализ производится с помощью двух независимых матриц, это фотограмметрический метод обработки синхронных стереопар изображений лиц. Но сам анализ не обязательно завязан именно на них. Это могут быть лазерные сканеры (как видимого спектра, так и нет), и так далее.

Ну и подводя итоги по данному способу распознавания, перечислю плюс и четыре минуса:

Плюс:

• Точность распознавания лиц на данный момент недостижима для 2D метода.

Минусы:

• Нельзя использовать “классические” 2D камеры.
• Отсутствуют готовые базы с распознанными лицами.
• Сложность добавления новых лиц в свою БД.
• Цена решения. Дорого? Не то слово.

б. Распознавание автомобильных номеров

Точно также, как и распознавание лиц, имеет свои правила, обеспечивающие бесперебойную и качественную работу детектора и системы в целом:

• Используется подходящее оборудование.
• Модуль аналитики в камере или на сервере работает корректно.
• Камера установлена правильно.

Можно возразить, ведь “мы читали это выше, ничего интересного больше не будет?”, поэтому я готов сказать - удивить есть чем. Зачастую, проблемы у монтажников начинаются еще на стадии выбора точки монтажа.

Максимальную точность распознавания даст камера, смонтированная по следующим правилам:

По высоте установки камеры выбирается исходя из разумных пределов: если повесим камеру низко, например, прямо на шлагбаум, то грязь от проезжающих машин быстро замарает объектив, качество детекций снизится, да и сотруднику придется бегать с тряпочкой и протирать стекло. Ровно противоположная картина ожидает нас, если повесить камеру слишком высоко: камера просто не сможет определить номер транспортного средства. Поэтому, зачастую, камеры вешают на высоте от двух, до шести метров (в случае, если расстояние до зоны распознавания более 15 метров и используется вариообъектив)

Угол наклона камеры относительно объекта распознавания не должно превышать 30 градусов по вертикали и 20 градусов по горизонтали.

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

Конструкция, на которую установлена камера, должна быть защищена от вибрации и раскачивания (не должна иметь эффект “паруса”, например). Особенно актуально, если используется вариообъектив, а расстояние до точки распознавания превышает 5 метров.

Важно понимать, что автомобиль может встать на таком расстоянии, что стрела шлагбаума будет перекрывать номер. Так как прозрачные стрелы не изобрели (да и водители сносили бы их еще чаще), следует продумать и этот момент. Отличным вариантом решения проблемы станет нанесение разметки на асфальте, перед которой автомобиль должен будет остановиться. Точное место нанесения разметки определяется в зависимости от точки установки камеры, тут вступает в дело геометрия.

Пример: как выбрать место для монтажа камеры

Окей, с правилами монтажа разобрались. Далее следует приступить к выбору оборудования. Если проскользнула мысль: “ща зарядим побольше разрешение, и, как грицца, будет все шикарно”, то как-бы мне не хотелось Вас расстраивать, но сделаю я это с превеликим удовольствием - это так не работает. Можно возразить: “но как, Вы же сами рекомендовали использовать большое разрешение камер на распознавание лиц, разве тут ситуация не такая-же?”.

А ситуация у нас в корне не такая же. Если в случае с распознаванием лиц мы можем реализовать все условия, которые повысят процент успешного распознавания (установим прожекторы, которые будут светить из-за камеры, поставим камеры большого разрешения и так далее), то при распознавании номеров ситуация будет сложнее.

Мы имеем следующие вводные:

• Изменяющееся время дня и ночи. Аналитика ведь должна работать 24/7, не так-ли?
• Ночью автомобиль будет засвечивать камеру своими фарами
• Возможный недостаток освещенности.

Предлагаю решать проблемы поочередно, и начать с выбора камер.

Крайне важно понимать, что в случае с аналитикой, экономить на камерах точно не следует, так как их качество и характеристики - важная составляющая успешной работы аналитики. Как говорилось выше, не стоит “вешать” на одну камеру разные задачи: определение номера и обзорное видеонаблюдение, получится в лучшем случае так себе. Правильнее будет повесить две камеры, и использовать одну в качестве обзорной (определить марку, цвет машины, опционально - увидеть пешеходов, идущих вдоль дороги или у подъезда к шлагбауму), а вторую в качестве инструмента для анализа.

Выбор разрешения камер

Как я сказал выше, правило ЧБТЛ (Чем Больше - Тем Лучше) здесь не работает. Задача не заключается в распознавании мелких черт или деталей, как в случае с распознаванием лиц, сейчас требуется распознать конкретный объект фиксированного (кроме случаев с мотоциклами) размеров.

При этом, нам нужно соблюсти баланс, ведь малое разрешение будет вызывать неточности и ошибочные распознавания, а высокое, в случае использования серверной аналитики, значительно увеличит нагрузку на используемую платформу.

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

Дабы говорить предметно, предлагаю сравнить 2 матрицы Sony Starvis: IMX307 и IMX335 (далее будут буковы и цифоры, если лень читать - можно спокойно проскочить один абзац.).

Обе матрицы имеют одинаковый размер: 1/2.8”, но разное разрешение: IMX307 - 2 Мп, а IMX335 - 5 Мп. При этом, физический размер пикселя у 307-ой будет составлять, согласно их даташитам, 2.9 μm (H) * 2.9 μm (V), а у 335-ой - 2 μm (H) * 2 μm (V). Плотность пикселей у 335-ой значительно выше, размер пикселя и количество попадаемого на него света - меньше. К чему это может привести? Как минимум, камера будет иметь меньшую светочувствительность, что в темное время суток может сделать номер нечитабельным (либо читабельным только для человеческого глаза, но не для модуля аналитики), и как итог - потребует дополнительное освещение на площадке, которое не всегда возможно установить, а также стоит денег.

Резюмирую кратко: выбирая между матрицами одинакового размера, но разного разрешения, следует опираться именно на меньшее число мегапикселей.  

Выбор объектива.

Объектив должен иметь максимальную светосилу, обеспечивать достойную резкость изображения как в дневное, так и в ночное время суток, а также, он должен предоставлять необходимый угол обзора.

В паспортах на камеры светосила объектива обозначается символом F/[число], например, F/1.4. Чем больше данное значение (F/1.4 > F/1.6), тем большую светосилу имеет объектив, что нам и требуется. Также, стоит понимать, что объектив с авторегулировкой диафрагмы (АРД) будет существенно эффективнее в условиях часто изменяющейся освещенности в зоне анализа, нежели объектив с фиксированной диафрагмой.

Тонкая настройка камеры.

Хотя-бы в этом пункте постараюсь быть действительно кратким.

WDR отключаем, так как он, зачастую, только вредит корректной работе детектора. Вместо него включаем HLC (High Light Compensation - компенсация яркой засветки).

Количество кадров выбирается исходя из конкретной задачи. Для определения номера перед шлагбаумом будет достаточно 12 к/с, в зонах с разрешенной скоростью до 40 км/ч потребуется уже 25 к/с, а для оживленных трасс следует использовать камеры с 60, а иногда и 120 к/с.

Скорость затвора также зависит от скорости проезжающего транспорта. Для зон с шлагбаумом, при использовании хорошего освещения - смело выставляем значение 1/250. Если транспорт едет на скорости 40-60 км/ч следует использовать значение в 1/500, и так далее.

Как ни странно, для распознавания номеров режим Ч/Б будет выгоднее, нежели цветное изображение.

Ну и наконец, камера должна иметь на своем борту аналитику номеров транспортных средств, либо этот “тяжкий груз” ложится на серверную платформу.

Освещенность в точке считывания

Итак, мы определились с выбором камеры, даже нанесли разметку, чтобы водители останавливались в нужном месте, осталось разобраться с последней проблемой - освещенностью.

Понятное дело, чем его больше, тем лучше: и охраннику, что сидит на КПП, и камерам, производящим видеоаналитику.

Существует два варианта реализации:

Установка дополнительного освещения видимого спектра

Установка ИК прожектора

Оба работают замечательно в тандеме, но важно понимать, как работает каждый из них. Установка обычных фонарей, прожекторов повышает общую освещенность на участке дороги, а также облегчает задачу обзорным камерам (мы же про них не забыли?). Но если установить их неправильно (например, поставить мощный прожектор на крышу КПП), то освещение будет слепить водителей, светя им в лицо и вызывая заслуженное недовольство, так делать не стоит.

Особняком стоит ИК подсветка. Она также бывает встроенной в камеры, но бывает и внешней, в виде прожекторов. В рамках данной статьи мы поговорим именно о последнем исполнении, далее по тексту Вы поймете, почему.

Технически, это тот же самый фонарь или прожектор, состоящий из корпуса, радиатора (ведь излишки тепла в процессе работы нужно рассеивать) и светодиодов с линзой. Отличие заключается в том, что светодиоды используются не обычные, а с конкретной длиной волны - начиная от 780, заканчивая 950 нм (нанометров).

Неоспоримый плюс подобных источников освещения - то, что их свет не виден человеческому глазу. Во время вечерней прогулки видели красные огоньки у камер? Так вот, это и есть ИК подсветка, просто встроенная в камеру.

С базой разобрались, переходим к нюансам.

В зависимости от длины волны, изменяется то, насколько эта подсветка заметна:

940-1000 нм. Подсветка глазу незаметна совсем. В качестве недостатка - дальность подсветки совсем небольшая, не более 15 метров. Кстати, светодиоды подобной категории применяют в пультах телевизоров: человеческий глаз свечение не видит совсем, а вот ИК-приемник или камера телефона их очень даже видит.

780-820 нм. Подсветка становится более заметной, но имеет преимущество в виде увеличенной дальности.

840-880 нм. Можно сказать, что это “золотая середина”, применяемая в большинстве оборудования, представленном на рынке. Подсветку по прежнему не видно, а дальность остается достаточной для видеонаблюдения.

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

Правило тут простое, чем шире угол, тем на меньшее расстояние способен светить прожектор. Регулируется это с помощью рассеивающих линз, встраиваемых в корпус при производстве. Большинство производителей делит свою продукцию на группы, например:

• Угол 90 градусов, дальность подсветки до 15 метров;
• Угол 60 градусов, дальность подсветки до 60 метров;
• Угол 10 градусов, дальность подсветки до 100 метров.

Предвижу фразу: “Вить, ну это уже какой-то маркетинг пошел, у нас же в камере есть ИК подсветка, она что, не сканает?”.

Да, она подойдет для реализации задачи, только есть нюанс - лето и насекомые.

 Пауки - не дураки!

Инфракрасный диапазон действительно не виден человеку. А вот насекомые его видят очень и очень хорошо - и с удовольствием летят на него. Этим регулярно пользуются пауки, сплетая свои сети и закрывая объектив паутиной. При этом, она отлично засвечивается ИК подсветкой, а сцена становится недоступна.

Используя камеру с выключенной ИК подсветкой (но с переводом в ч/б режим, это важно!) и внешний ИК прожектор мы минимизируем ущерб, который можем получить в летнее время.

Да, прожектор по прежнему остается лакомым кусочком для пауков и насекомых (но даже с паутиной перед ним, он будет выполнять свою главную и единственную функцию, а вот камера мгновенно станет им неинтересна.

Что-ж, с видами подсветки мы разобрались, осталось определиться с местами установки.

    Наглядная рекомендация по установке источников освещения

Инфракрасные источники освещения устанавливают рядом с камерой, чтобы избежать отражений и появлений теней, при этом они направляются на центр зоны контроля. Дополнительное освещение видимого спектра устанавливается как можно выше (фонарные столбы, крыши зданий), так как их задача - увеличить общую освещенность сцены. Важный совет: источники белого света стоит размещать симметрично, чтобы избежать излишне освещенных и затененных участков.

При соблюдении представленных выше рекомендаций, проблемы с распознаванием номеров будет решена

4. Обнаружение, а не распознавание!

Нередко встречаются проекты, в которых есть необходимость в распознавании лиц. Например, представленный в первой статье пример кросс-чекинга.

При этом, монтажники без опыта реализации подобных задач, закладывают оборудование, которое поддерживает обнаружение лиц. 

Звучит похоже, и там и, там есть лица. Казалось-бы, что не так?

А дьявол, как ни странно, кроется в деталях.

Обнаружение лиц - аналитика, способная выхватить лицо в кадре, сделать кроп этого лица (обрезать его) и сохранить куда-то в память камеры/сервера.

Распознавание лиц - аналитика, направленная на идентификацию лица в базе данных, при этом она тоже умеет обнаруживать лица в кадре, после чего заносит их в список незнакомых или “гостей”.

Говоря простым языком, если нам нужно быть уверенным, что в кадре присутствует конкретный человек (и, впоследствии, выдать конкретные права, либо отследить его перемещение), то используем аналитику распознавания лиц. В случае, если нам не нужна идентификация, то применяем обнаружение.

5. Зоопарк из камер и регистраторов

Большинство производителей оборудования для систем видеонаблюдения закладывает видеоаналитику исключительно при использовании оборудования собственного бренда. Разумеется, это вводит свои коррективы при реализации проекта и стоит учитывать данный факт.

Важно понимать, что подобное ограничение можно обойти, используя серверные решения, так как зачастую, они работают исключительно с ONVIF / RTSP потоком.

6. Слабая “физика” объекта

Данная проблема затрагивает не только работу аналитики, но и работу системы видеонаблюдения в целом. 

Думаю, не стоит говорить о том, что в случае, если пропускная способность интерфейсов регистратора/сервера будет недостаточной, Вы столкнетесь с определенными проблемами, причем они могут быть как плавающими, так и относительно “стабильными”: онлайн поток и архив могут записываться с прерываниями, либо наоборот - при локальном просмотре на сервере, система работает штатно, а вот при использовании УРМ - онлайн-трансляция будет обрываться. 

Дабы такого не было, следует заранее просчитать примерный битрейт от камер, который будет ходить в локальной сети, а также, закладывать трафик, который будет идти от сервера/регистратора к УРМам.

Ну тут уж совсем все просто. 

Выводы

Подведем промежуточные итоги по статье.

В третьей статье мы разобрали типичные ошибки, которые может допустить монтажник при проектировании и монтаже системы видеонаблюдения, а главное - получили рекомендации по правильной установке камер. Придерживаясь этих немногочисленных правил, у Вас получится реализовать надежную, а главное точную и достоверную аналитику.

Да, подготовить такой материал было совсем не просто. 

Искренне надеюсь, что Вы смогли найти в данном курсе что-то полезное для себя, закрыли какие-либо “пробелы” в знаниях и обучились новому. Если быть откровенным, то в процессе написания статьи даже мне удалось узнать для себя новые детали (пусть и не описанные в статье, так как они слишком углубленные для данного формата) о работе аналитики в видеонаблюдении.

Пользуйтесь и развивайтесь, коллеги!

Предустановленные в камеру аналитики. Как они работают?

Как я сказал ранее, встроенная видеоаналитика крутится на самом устройстве. Что, как бы, логично. :)

Использование специализированной аналитики на борту камеры является наиболее правильным решением при построении системы видеонаблюдения (СВН). У данного метода есть множество плюсов:

• Аналитика затачивалась под конкретное устройство видеонаблюдения. Это означает, что процесс анализа будет максимально оптимизирован и эффективен (насколько это, разумеется, позволяет железо).
• Снижение общего трафика, что ходит по сети. Например, можно реализовать передачу первого потока только в случае, если в кадр попадет человек, в противном случае будет идти только второй поток.
• Мы значительно снижаем нагрузку с конечного записывающего устройства (сервер, или регистратор), так как от камеры идет и поток, и уже обработанные метаданные.
• Появляется возможность реализовать взаимодействие со внешними устройствами, например, через тревожный выход замыкать управляющее реле от прожектора (или рупора сигнализации).

Казалось бы, отлично, дайте побольше камер, сейчас сделаем супер-аналитику!
И все было бы круто, если бы не одно но…

Темная сторона такого решения заключается в том, что:

• Мы имеем определенное производителем число аналитик. Исключением из правил можно назвать HEOP от HikVision и платформу AXIS, куда можно подгрузить собственноручно написанную аналитику.
• Нагрузка на камеру возрастает, причем солидно. Теперь, помимо оцифровки сигнала от матрицы, процессор (либо его сопроцессор) должен еще и произвести определенные действия (о чем поговорим далее). Соответственно, в камере должна быть большая вычислительная мощность (ТФЛОПС). Камеры некоторых производителей имеют на борту мощность вплоть до 10 ТФЛОПС, что, разумеется, стоит очень и очень недёшево.
• Для полноценной работы аналитики требуется чип APU/IPU, который снимает вычислительную нагрузку на себя. В случае его отсутствия в камере, аналитика может работать некорректно.
• Зачастую - это невозможность переобучить нейросеть для аналитики (а это важно).
• Почти всегда для адекватной работы аналитики систему требуется строить на монобрендовом решении, что также удорожает проект.

Как можно заметить, данный сценарий - палка о двух концах. С одной стороны - возможность сделать свою систему видеонаблюдения “умной”, а с другой - в случае, если СВН уже развернута, придется менять уже установленные на объекте камеры, что встанет в определенную сумму (при этом, снятые камеры нужно будет куда-то деть, либо держать в качестве запасных).

Что происходит внутри камеры?

Есть-ли в камере ИИ? Нет конечно, его как такового не будет года эдак до 2061.
Есть-ли в камере нейросети и “глубокое обучение”(deep learning) - определенно, да! И именно нейросеть и машинное зрение помогает “отсекать” ненужные события.

Когда-то давно в камерах использовали OpenCV, теперь же на смену ему пришли такие модули как SSD (Single Shot Detector - не путать с Solid State Driver!) и YOLO (You Only Look Once, недавно обновившийся до версии v8). Разумеется, нейросети различаются по своему быстродействию и точности срабатывания: когда одни модели быстро реагируют, но чаще “мажут” мимо цели, другие действуют медленнее, зато и процент ошибок значительно ниже. Предлагаю рассмотреть определенные, достаточно распространенные аналитики, которые можно реализовать на данных нейросетевых моделях.

Первая аналитика, которую я хотел бы разобрать - “Обнаружение человека/автомобиля” (или же IVS/AcuSence и так далее). Если говорить кратко, то в ней работает такая технология, как “Метод фонового вычитания”.

Об этом есть интересные статьи на хабре (и не только). Специально в рамках данной статьи я подобрал для вас целых три, уверен, что это будет интересно прочитать:

• OpenCV
• YOLO
• Трекинг объектов

Ну, а для тех, кому “Многобукаф, не хочется читать…”, я сделаю максимально краткий и поверхностный пересказ данных статей, так как нейросети работают по похожему принципу и отличаются скоростью, точностью (ну и некоторыми фичами, конечно же).

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

Опустим момент с развертыванием нейросети, так как это, разумеется, база. Сразу после развертывания начинается самый важный и ответственный этап любой взрослой нейросети - обучение.

Для нейросети подготавливают определенный объем размеченных данных, в контексте видеонаблюдения, это зачастую картинки (видео тоже можно загружать, и это, как ни странно, повысит точность определения, но и объем датасетов вырастет в разы), главное условие - единая размерность, например, 500х500 пикселей. Если картинка больше - ее сожмут, если меньше - то дополнят черным по краям, чтобы увеличить. Затем, системе “скармливают” расшифровку - маски этих картинок.

Далее, происходит “дробление картинки на сегменты” / grid cells (если речь идет о YOLO-модели), привязываются Bounding boxes (либо anchor boxes) - те самые “прямоугольнички”, которые обводят в кадре интересующий нас объект.

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

После того, как нейросеть обучится, мы получим детектор, который способен отображать интересующие нас объекты и отсекать ложные срабатывания. И все бы здорово, но с этим массивом данных тоже нужно работать. Поэтому в ход идёт ReID посредством DeepSort (на самом деле, вариантов масса), и о чудо - нейросеть способна сортировать и передавать метаданные.

Как я говорил выше, использование нейросетей повышает требования к аппаратной части камеры, и даже несмотря на более “жирную” начинку, большинство камер может работать с аналитиками только по паттерну “или, или”. Или обнаружение человека, или детекция лиц, к примеру. И лишь единичные модели у high-tier вендоров способны в работу “и, и”, при этом они тоже имеют свои нюансы.

На ноябрь 2024 года розничная стоимость камер Omny со встроенными аналитиками начинается от 9000 рублей

Аналитика в регистраторах

Алгоритм работы встроенной аналитики в регистратор точно такой же, как и в камерах (иногда, они обучаются на том же датасете, да и в целом, зачастую идентичны), поэтому нет смысла расписывать логику обучения заново. Плюсов в использовании аналитики исключительно на регистраторах, при построении СВН, меньше, а минусов - больше.

Перечислим плюсы:

• Главный плюс: возможность использовать интеллектуальные аналитики на уже установленный парк видеокамер (и то, с большим нюансом, о чем я расскажу далее).
• Как и в случае с камерами, мы имеем возможность реализовать взаимодействие со внешними устройствами посредством тревожных выходов на самом регистраторе.
• Возможность ведения единой базы данных (например, при использовании распознавания лиц), создания правил использования для конкретных камер.

А вот минусов, в данном случае, значительно больше, но оно и не мудрено, мы комбинируем в записывающем устройстве еще и AI-функционал:

• Как и в случае с камерами, число аналитик весьма и весьма скудное, а детекторы - необучаемы.
• Даже несмотря на то, что регистратор имеет встроенные аналитики, зачастую он способен анализировать картинку лишь с пары камер (обычно не более двух, а если разрешение камеры слишком высокое, порядка 8 Мп и более, то вовсе лишь одной). Связано это, как понимаете, с недостаточной производительностью встроенного процессора.
• Исходя из пункта выше - скорость работы аналитики, установленной в регистратор значительно ниже, так как устройство вынуждено комбинировать в себе сразу несколько действий - анализ и запись на жесткие диски.
• При использовании регистратора в качестве платформы для аналитики, мы повышаем нагрузку на него, ровно как и тепловыделение. В конечном итоге, это может привести к некорректной работе регистратора в целом.

Несмотря на присутствующие системе минусы, я все-же рекомендую использовать “умные” регистраторы вместе с камерами (конечно же, поддерживающими аналитику), особенно, когда речь идет о монобренде. Причина невероятно проста. Используя регистратор Omny с поддержкой метаданных, нам открывается возможность использовать наш интеллектуальный поиск “AcuSearch” в архиве (привет, AcuPick от Dahua) и прочие аналоги от сторонних производителей.

В конечном счете, это решает следующие задачи:

• Снижение требований к навыкам охранников (просто обведи интересующего человека мышью, и регистратор выдаст все кадры с камер, где присутствует этот человек).
• Увеличение скорости операций по поиску конкретного события (по схожим причинам).

На время написания этой статьи (а это ноябрь 2024 года) регистраторы Omny со встроенными аналитиками стоят от 17000 рублей

Внешние устройства аналитики

Внешние устройства аналитики являются промежуточными между камерой и регистратором / сервером.

Точно так же имеет заранее заготовленные аналитики, обученные по датасетам производителя. Платформа получает поток от камер, анализирует его, а далее отправляет обработанный поток метаданных, которые понимает (это важно!) регистратор. Пройдемся по плюсам и минусам.

Плюсы:

• Устройство способно обрабатывать значительное количество камер одновременно (48 различных камер, к примеру).
• Отсутствует как таковая нагрузка на регистратор и камеры. Устройство шлет готовые метаданные напрямую в регистратор.
• Нет необходимости в смене парка установленных камер. Как я сказал ранее, устройство получает поток от камеры, обрабатывает его и передает в регистратор, именно поэтому можно использовать ранее установленный “зоопарк” камер разных производителей.

Как ни странно, у данного способа также имеются недостатки.

Минусы:

• Стоимость устройства. Да, оно продвинутое, и закрывает задачу с лихвой, но вот цена будет сильно кусаться.
• Регистратор и устройство аналитики должны быть от одного производителя, а также регистратор обязан понимать метаданные, которые шлет устройство. В противном случае, все метаданные уйдут “вникуда”.
• Как и в случаях с аналитикой на камерах и регистраторах, есть лишь небольшой список аналитик, предлагаемых производителем, кроме того, не на каждом устройстве можно переобучить детектор.

Средняя стоимость подобных аналитических платформ от сторонних вендоров начинается от 360000 рублей.

Серверная видеоаналитика

Если рассматривать систему видеонаблюдения, построенную на основе полноценных серверных платформ, то можно провести прямые параллели с системами на регистраторах. И это вполне логично, ведь сервер действительно можно рассматривать как большой, мощный регистратор с расширенным функционалом.

Безусловно, можно приобрести бюджетное решение (но, зачастую, к серверным исполнениям приходят тогда, когда объем камер большой) и использовать его как регистратор с расширенными возможностями, к примеру - использовать шасси на 24 жестких диска.

Как я писал ранее, большинство производителей серверов для видеонаблюдения продают “голые” шасси - комплект железок, из которых состоит сам сервер, устанавливают ОС (чаще всего debian, реже - windows), поверх которой накатывают оболочку (GUI), либо оставляют сервер без локального отображения. Для того, чтобы программа могла взять RTSP-поток с камер, либо подключиться к ним по ONVIF, требуются лицензии специализированного ПО (модули аналитики зачастую продают как отдельную позицию), у каждого из производителей они имеют свое название. Например - OmnyVideo.

Достоинства данной системы неоспоримы - система достаточно гибкая, а самое главное - масштабируемая, что в случае расширения парка используемых камер, будет лишь плюсом. “Взрослые” серверные решения можно резервировать по модели N+M, вводить в эксплуатацию (или выводить из нее с сохранением всего записанного объема информации) стримеры, менять шасси серверов для увеличения количества используемых дисков, и не только.

В рамках аналитик, серверные решения являются наиболее гибкими и настраиваемыми, даже в сравнении с аналитиками на борту камер. Возможность переобучить ReID-алгоритмы, а также выполнить переобучение системы в целом.

Большинство (почти все, на самом деле) производителей видеоаналитики используют в качестве источника вычислительной мощности именно графические процессоры, за счет соотношения цена/производительность. Благодаря этому и достигается увеличение количества доступных аналитик. Никто не мешает доукомплектовать шасси десятком Nvidia Quadro и получить мощную платформу аналитики, которая еще и умеет строить рейды (а иногда, даже иметь дублирующий контроллер, который обеспечит сохранность информации), либо пойти другим путем - увеличить количество серверов и получить такую же вычислительную мощность.

И даже пропускная способность не станет серьезным ограничением. Если необходимо - можно установить дополнительные сетевые карты, хоть 10-гигабитные.

Также, нельзя забывать о возможности написания специализированных модулей аналитики под конкретные задачи (к слову, OmnyVideo может предложить и это).

Лишний раз повторюсь, что суть работы нейросетевого детектора максимально похожа на те, что “крутятся” на камерах, регистраторах и так далее. Сервер получает живой поток от камеры и прогоняет через развернутую нейросеть, добавляя метаданные.

Правда, стоит понимать, что при использовании продвинутых GPU (особенно, если их несколько в одном сервере) придется позаботиться об охлаждении, и и речь сейчас даже не об условных “отвалах” видеочипа.

Думаю, никто не станет спорить, что GPU имеют колоссальное тепловыделение (привет, high-end решения). А что еще имеет приличное тепловыделение при постоянной эксплуатации? Как это правильно говорится: “Прямо бинго!” - жесткие диски.

Что может быть лучше, чем хороший сервер? Несколько хороших серверов!

Если говорить кратко - при необходимости производить сложный анализ, а также хранить архив большого объема, следует разделить данный функционал на два разных сервера. При этом, стоит позаботиться о реализации охлаждения стойки в целом, при помощи кондиционера.

В финале подраздела предлагаю подбить в кратком виде плюсы и минусы подобной системы:

Плюсы:

• Возможность использовать камеры почти любого производителя - лишь бы шел RTSP поток. При этом, сложные аналитические процессы можно подвязать к уже установленным камерам, даже если они дешевые.
• Аналитика на серверах почти всегда является обучаемой: детектор можно перенастроить, в него можно подгрузить иной датасет (например, на заводе инженеры носят не белые каски, а фиолетовые. Классический детектор головных уборов не определит каску, а вот обученный на собственных данных - с легкостью).
• Колоссальная масштабируемость - можно объединить в кластеры несколько стримеров, либо увеличить вычислительную мощность конкретного сервера.
• Аппаратные RAID-контроллеры с возможностью дублирования массива.
• Кастомные аналитики, произведенные и обученные под конкретные задачи на заказ.
• Недостижимая для классических регистраторов глубина архива.
• Отсутствие упора в пропускную способность сетевого адаптера - возможность добавить дополнительные.
• Резервирование СВН по принципу N+M, когда в эксплуатации находится некоторое количество стримеров, а дублирующие простаивают до первой внештатной ситуации.
• Относительная свобода по выбору аппаратной составляющей сервера.
• Гибкость в выборе используемых аналитик.
• Аналитический поиск в архиве.

Минусы:

• Более высокая стоимость готового и укомплектованного сервера по сравнению с решениями на базе камер и регистраторов.
• Сервер имеет большие габариты, особенно, с большим архивом, поэтому крайне желательно место в стойке/шкафу.
• Как и любое электронное устройство с высокой производительностью, сервер сильно греется, соответственно - шум от системы охлаждения очень сильный.
• Не все производители готовы предоставить полноценную кастомизацию продукта под задачи клиента (либо делают это только для большого объема поставляемого оборудования и увеличенной стоимости проекта в целом).
• Для длительной работы крайне желательно использовать два раздельных устройства в качестве сервера хранения и сервера аналитики.

Также, у серверной платформы есть одновременно и плюс, и минус в одном лице: приобретая полноценное железо мы остаемся свободными в выборе используемого ПО, и вольны пересесть с одного на другое, если так захочется. Минусом же является тот факт, что ПО может работать некорректно, либо вовсе не заведется, так как требования к аппаратной составляющей у каждого производителя свои.

На ноябрь 2025 года стоимость серверных платформ Omny начинается от 270 тысяч рублей.

Облачная аналитика

Облачная аналитика является относительно свежим направлением в видеонаблюдении, как и облачные сервисы, в целом. Чисто технически, разница заключается в том, что мощный сервер находится не у вас в серверной, а в ЦОДе производителя, он же и отвечает за техническое обслуживание и сохранность записываемых данных.

Решение интересное, которое имеет свои плюсы и недостатки.

Плюсы:

• Значительная экономия на оборудовании. Как и в случае с локальной серверной аналитикой, к облачному сервису OmnyVideo можно подключить буквально любое оборудование, и аналитика будет работать полноценно.
• Отсутствует необходимость размещать свой сервер, периодически обслуживать его и следить за состоянием установленных дисков.
• Безопасность - злоумышленник не сможет украсть записи с доказательствами собственного преступления, так как архив находится на удаленном сервере.
• Масштабируемость - достаточно просто подключить дополнительные камеры и оплатить тариф.

Минусы:

• Самый главный - необходимость в стабильном и постоянном интернет соединении для трансляции потока от камер.
• Тарифная система. Камеру нельзя подключить к облаку на бессрочной основе, а большинство фирм, предлагающих облачную аналитику и хранение предлагают “пакеты” хранения - 3, 7 дней и так далее.

Выводы

Думаю, после прочтения у вас появилось понимание, каким образом работает “магия” внутри оборудования видеонаблюдения, а также, какими преимуществами и недостатками обладают способы реализации аналитики.

Что же будет дальше? Ровно то, что я анонсировал во вступлении - в следующей статье проведу разбор ошибок монтажников и рекомендации по установке камер видеонаблюдения.

1. Что такое видеоаналитика, и зачем она нужна?
2. Разделение видеоаналитик по платформам.
3. Разбор проблем при вводе аналитики в эксплуатацию, рекомендации к выбору оборудования и монтажу.

Приступим!

Вводная часть. Что такое видеоаналитика, и зачем она нужна?

Идут годы, приходят и уходят различные вендоры видеонаблюдения, растет вычислительная мощность серверов и регистраторов, активно наращиваются мегапиксели в камерах, также развивается и аналитика.

Думаю, мне не стоит расписывать, что видеонаблюдение применяется для сбора доказательной базы таких правонарушений, как:

• воровство;
• драки, грабежи;
• нарушение ПДД, и так далее.

Список можно продолжать бесконечно, какие-то действия хорошо описаны в УК РФ и КоАП РФ, другие же действия просто порицаются обществом и считаются неприемлемыми. И если бы не технологический прогресс, то вплоть до наших дней, охране приходилось бы 24/7 лицезреть видео с камер наблюдения. И всё бы почти хорошо, но человек несовершенен. 

Вариантов несовершенств множество:

• Моральная или физическая усталость.
• Социальное влияние (сговор).
• “Шум”, от которого человек не может отвлечься.
• Профессиональное выгорание.
• Низкая квалификация сотрудника.
• Различные когнитивные искажения.

Где-то здесь должен быть эпизод с коронной фразой Адама Смэшера: “Тело тебя подводит” и “Плоть - слаба”. :)

Но технологический прогресс ещё не ушёл настолько далеко вперед, да и живем мы пока не в эпоху киберпанка (но стремительно к ней движемся, чего стоят только глазные импланты со встроенными в камерами), поэтому использовать пока мы будем те инструменты, что нам доступны здесь и сейчас. Видеоаналитика поможет нормальному живому человеку справиться с любым объемом задач. Ведь предварительную обработку изображения можно переложить на вычислительные мощности.

Видеоаналитика — это технология, основанная на применении методов компьютерного зрения для автоматизированного извлечения данных путем анализа видеопотоков, получаемых в режиме реального времени или из архивных записей.

Аналитика позволяет свести, а также обработать всю информацию, отсечь “шум” в виде статического изображения или отсутствия нарушений, и донести лишь критически важную информацию в пункт централизованного наблюдения (далее по тексту - ПЦН), или же в уведомлении, поступающем на смартфон. Именно аналитика способна гарантировать, что вы не пропустите попытку проникновения на свой объект, либо потерю дорогостоящего имущества (за которое придется работать 510 лет).

Сферы применения аналитик

Аналитик существует почти безграничное множество, и каждая из них создана для решения определенных задач. Конечно, нельзя однозначно отнести ту или иную аналитику к какой-либо группе, поскольку они, зачастую, универсальны. Предлагаю сгруппировать их, исходя из общего функционала.

Охранная видеоаналитика

Исходя из названия, становится ясно, что “профессиональная ниша” данного вида аналитики - пресечь следующие правонарушения: неправомерное нахождение на какой-либо территории, кражи, обнаружение оставленных вещей и так далее. Самыми яркими примерами подобных аналитик можно назвать, уже ставшие классическими, детектор движения, детектор обнаружения людей или транспорта, пересечение линий, обнаружение вторжения и так далее. Несмотря на то, что аналитика может работать в комплексе с системами оповещения, ей по-прежнему нужен человек, ведь камера не способна задержать нарушителя. Правда, в Африке уже предприняли первые шаги к решению данной проблемы.

Несомненный плюс данного типа аналитики - это снижение количества ложных тревог, а также возможность классифицировать события, как при просмотре в реальном времени, так и при просмотре в архиве. 

Благодаря видеоаналитике, снижается нагрузка на оператора ПЦН, так как ему больше не требуется всматриваться в каждую камеру постоянно, а приходится реагировать с особой тщательностью только на события по тревоге. Также, снижается количество сотрудников, которые требуются для непрерывного наблюдения за безопасностью на объекте. Так, если в классическом видеонаблюдении охранник при длительной работе не способен просматривать более 9 камер с различным позиционированием (вспоминаем про такое несовершенство человека как усталость, “замыливание глаза”, скука и так далее), то при использовании аналитики, количество камер можно увеличить до 16, оставив для постоянного наблюдения лишь камеры с наибольшим интересом (открытые складские площадки, критически важные проходы и так далее).

Видеоаналитика для бизнеса

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

Благодаря видеоаналитике, бизнес становится более контролируемым, а самое главное - прогнозируемым, получает конкретные метрики. Из наиболее популярных хотелось бы выделить такие аналитики, как: интеграция и контроль кассовых операций (POS), видеофиксация получаемых купюр, подсчет посетителей, контроль наполненности полок в магазине, а также тепловая карта, позволяющая проанализировать, какие полки привлекают посетителей сильнее, а какие наоборот - простаивают.

Как и говорил выше, существуют такие аналитики, которые не могут быть отнесены к той или группе, и один из ярких примеров - обнаружение и распознавание лиц. Если рассматривать данные аналитики в разрезе предотвращения правонарушений, то их функционал - зафиксировать лицо правонарушителя, чтобы эти данные можно было передать в правоохранительные органы, либо провести внутреннее расследование и применить какое-либо наказание.

Также, предлагаю рассмотреть следующий способ применения аналитики: распознавание пола, возраста посетителя и последующее формирование целевой аудитории, посещающей магазин. Дальнейшим же этапом будет использование данных ЦА для планирования ассортимента товаров. 

Кроме того, комплекс из СКУД и распознавания лиц позволяет реализовать 100% контроль за учетом рабочего времени сотрудника, а также, быть уверенным, что по его пропуску не отмечается коллега или случайный человек.

Все популярнее становится аналитика очередей на кассе, особенно в нише розничной торговли. В случае, если количество людей в очереди превышает определенное значение, в ПЦН приходит уведомление, после чего оператор может отправить дополнительного кассира. Грамотно настроенная аналитика позволяет повысить лояльность со стороны клиентов по отношению к бизнесу, оптимизировать трудозатраты сотрудников и увеличить положительный отклик от посетителей.

Производственная аналитика

В первую очередь, данная аналитика предназначена для снижения травматизма на производстве, так как данная проблема по прежнему является крайне актуальной на всех производствах и не только. Так как ответственность за производственные травмы сотрудников несет исключительно работодатель, предприятия закладывают бюджеты на повышение безопасности выполнения труда, а также на возможность мониторинга в реальном времени качества соблюдения работниками требований охраны труда. При этом, причиной производственного травматизма не всегда является именно работодатель. Зачастую, причиной травм является сам сотрудник и его невнимательность, нахождение в опасной зоне, а также пренебрежение использованием СИЗ.

Для решения данной проблемы и следует применять видеоаналитику. Она способна в автоматическом режиме отслеживать ношение сотрудниками СИЗ, что снижает риск травматизма, а также отправит уведомление, если персонал находится в потенциально опасном месте. Также, данные технологии хорошо дисциплинируют работников, так как материальное наказание за нарушение избежать не удастся, система аналитики беспристрастна и с ней нельзя “подружиться”. С учетом того, что анализу подвергается не статичное изображение, а видеопоток, шанс обнаружения какого-либо нарушения приближается к 100% (в зависимости от того, насколько большой объем данных был изначально загружен в нейросеть для обучения, но об этом - в следующей главе).

Также, существуют специализированные устройства, совмещающие в себе СИЗ и записывающие устройства, например - каски.

Одна из реализаций комбинированного СИЗ с аналитикой

Кроме того, в некоторых из них есть встроенные датчики удара, гироскоп и так далее, что позволяет в случае предположительного падения или травмирования человека отправить сигнал на ПЦН, где оператор первым получит уведомление и сможет оперативно среагировать в рамках сложившейся ситуации.

Специализированная аналитика

Справедливости ради, любую аналитику можно назвать “специализированной”, так как она решает конкретные задачи. В данный раздел я решил вынести специфичные кейсы и применение составных аналитик. 

К таким можно отнести такие аналитики, как:

• Распознавание номеров на колесных парах для поездов.
• Контроль заполненности кузова грузового автомобиля.
• Контроль вывоза ТКО.

Важно учитывать, что в данном разрезе аналитики зачастую работают в полноценном комплексе, дополняют друг друга и отсекают лишние события.

Давайте рассмотрим кейс с вывозом ТКО.

Имеем классическую открытую/закрытую (нужное подчеркнуть) площадку с контейнерами сбора мусора. Понятное дело, этот мусор нужно вывозить с некоторой периодичностью, но так как человек - существо непостоянное (а, зачастую, еще и непредсказуемое!) при условно “плановом” вывозе мусора мы можем получить 2 варианта развития событий:

1. Контейнеры для сбора мусора будут наполовину пусты, при этом мы потратим бензин и время сотрудников на вывоз мусора.
2. Контейнеры могут оказаться переполненными, из-за чего мусор будет складироваться “горой”, вываливаться из хранилища, либо его вовсе будут складывать рядом с контейнерами.

Если первый вариант несет убытки лишь УК, то при втором развитии событий, неудобства испытывают все: и сама УК, и ее сотрудники (поднимать огромную кучу мусорных пакетов с пола и забрасывать их в спецтранспорт то еще удовольствие), а самое главное - жильцы. Конечно, если под управлением есть несколько домов, то проблема решается все тем же периодическим контролем контейнеров с камер: есть-ли что-то внутри или нет. А вот если подконтрольных домов становится больше, то постоянно наблюдать становится значительно тяжелее. 

В данной ситуации нам помогает одновременно две аналитики:

Первая - контроль заполненности контейнеров с отходами. Если описывать ее в двух словах, то это: в случае, если мусор по высоте превышает “виртуальную границу”, то в ПЦН отправляется уведомление, например: “Дом@адрес+номер, контейнер ТКО заполнен”. После этого, оператор сможет целенаправленно отправить машину для забора отходов.

Вторая - скорее дополнительный контроль. Аналитику можно настроить так, чтобы система отправляла уведомления об успешном вывозе мусора, при этом не срабатывала на другие условия. Например:
когда приезжает мусоровоз, камера замечает его и начинает сравнивать с машинами, заранее занесенными в базу данных. В случае, если сравнение успешно, система отправляет сообщение: “Вывоз мусора из дома@адрес+номер совершен успешно”, а на временной шкале в архиве ставится метка. В дальнейшем, данную информацию вместе с видеопотоком можно будет предоставлять в случае спорных ситуаций с жильцами.

И таких кейсов может быть огромное множество.

Общее представление о стоимости

И в данном разделе мы подходим к самому интересному и животрепещещему вопросу, которым задается любой монтажник видеонаблюдения.

Сколько же стоит аналитика? Разумеется, каждый из нас хочет получить лучшую аналитику ЛЮБОЙ ЦЕНОЙ! Но бесплатно.

Конечно, фраза выше звучит словно шутка, но в наше время действительно можно получить весьма серьезную аналитику бесплатно (хоть и условно). Почему именно условно? Несмотря на “бесплатность”, стоимость интеграции аналитики уже заложена в конечную стоимость камеры. Получается, что вы приобретаете камеру, а аналитику получаете как бы “в подарок”. При этом стоит понимать, что камера, в данном случае, должна быть не простая (а золотая!), в идеале на борту должно быть более мощное железо (об этом - уже в следующей статье).

К слову, аналогичная ситуация и с NVR / XVR: для работы аналитики требуется более мощное железо, соответственно, и стоимость такого оборудования будет выше, чем у устройства без аналитики. 

Предлагаю также рассмотреть специализированные решения для аналитики. Они представляют собой небольшие краевые устройства с предустановленными аналитиками. По сути, оно перехватывает поток, исходящий от камер, обрабатывает его, а затем отправляет в регистратор или сервер. 

IVD5148WT-1I - яркий представитель краевых (edge) устройств

А вот с серверными платформами ситуация становится значительно интереснее.

Почти все крупные игроки на рынке продают исключительно собственные “шасси”, или “платформу”. При этом, аналитик на борту нет. Почему?
На самом деле, все до боли просто - это позволяет проектанту заложить именно те алгоритмы, которые будут использоваться, что снижает стоимость конечного продукта и повышает гибкость системы в целом.

Несомненно, у каждого из представленных выше методов есть свои плюсы и минусы. Именно об этом мы поговорим в следующей статье.

Выводы

Считаю, что данной статьей я смог внести ясность, почему видеоаналитика - “это очень хорошо, это нам очень надо!”. Пусть и грубо, но разграничил аналитики, согласно их рабочему функционалу, и рассказал, на каких железках эта самая аналитика может крутиться. 

Интервью в оригинальном виде можно посмотреть и послушать на RuTube.

История дела

C 2020 года операторы связи ведут борьбу с Россетями по поводу тарифов на подвес ВОЛС к ЛЭП. В этой борьбе важную роль играет ФАС. К сожалению, в последнее время ФАС все больше защищает интересы монополиста.

В июне 2024 года Битрейс телеком (Сергиев Посад) подал в ФАС Московского региона заявление о том, что тарифы Россетей экономически не обоснованы и монопольно завышены. По закону, тарифы монополиста должны составлять себестоимость плюс разумная маржа. Но Россети ставят на доступ произвольные тарифы. ФАС обязана рассматривать такие дела. 

Кроме Битрейса, заявления подали еще 10 операторов из Московского региона. ФАС РФ забрало дело из ФАС Московского региона. Параллельно был похожий процесс против Россети Волга со стороны группы операторов Приволжского ФО. Есть серия проигранных в ФАС дел Россетями. Против уже ФАС есть судебное решение и штраф. 

Мы считаем, что ФАС осознанно выбрало тактику затягивания. 

В декабре 2024 года операторы связи подали в суд уже на ФАС, по поводу того что ФАС бездействует.

В ноябре 2025го года Россети Московского региона снизили тарифы с 97 рублей до 49,5 рублей. После этого ФАС заняло следующую позицию в суде: ФАС не бездействует, работает с монополитстом и, в итоге этой работы ФАС, тарифы на подвес ВОЛС снижены.

Теперь подробности судебного заседания дела операторов связи против ФАС. 21 октября было первое заседание арбитражного суда. Пришло много операторов связи и пресса. Суд задал впрямую вопрос к ФАС: “Сколько вы можете рассматривать дело?”. На что ФАС ответил, что "они не бездействуют и плотно работают с Россетями”.

Назначили второе судебное заседание на 6 ноября, которое потом перенеслось на 11 ноября. 7 Ноября на сайте Россетей и ФАС разместили информацию, что Россети в добровольном порядке снизили тарифы и исключили из тарифов расходы на переустройство. 10 ноября прошло судебное заседание, на котором суд принял решение об отказе действий против ФАС в связи с тем, что ФАС выполнил свою работу и убедил Россети снизить тарифы.

Кто из Операторов связи подавал иск? Изначально, это была группа операторов Московского региона (Битрейс, Плей телеком, Инко, Интпром, Геогрин и еще ряд операторов). Но, в конечном итоге, истцом стал один оператор - Кварт. Остальные проходили по делу как свидетели

Ключевой аргумент Истца: есть закон о Защите конкуренции и регламент ФАС, по которому они обязаны в срок за три месяца или возбудить дело, или отказать в возбуждении дела.

Ключевой аргумент Ответчика (ФАС): ФАС признает, что нарушает сроки, но, во-первых, это нарушение не является пресекательным (не влечет последствий), а во-вторых, они не бездействуют, а плотно работают с Россетями, запрашивают документы, анализируют их. Это много работы, требующей увеличение сроков. Признаки нарушения антимонопольного законодательства ФАС видит и ведет соответствующую работу.

Решение суда: поскольку Россети добровольно понизил тарифы, то нарушения со стороны ФАС суд не признает.

Вывод.  Есть позитивный момент - комбинацией судебного давления на Россети, обращений в ФАС и судебного давления на ФАС удалось убедить Россети снизить тарифы с 97 до 49,5 рублей. Негативный момент - Россети продолжают считать учетной единицей не опору, а устройство. Что приводит операторов к очень серьезным расходам. В этом вопросе Россети противоречат разъяснениям Минцифры и разъяснениям Администрации Президента РФ, по которому единицей тарификации должна быть одна точка крепления линейной арматуры, а не устройство.

Как развиваются дела Операторов Связи против Россетей по всей РФ и как развиваются оспаривания тарифов через исключение расходов на переподвес?

Разбирательства в ФАС идут с 2021 года. Есть методика расчета тарифов Россетей, где они включают в свою себестоимость расходы на переподвес. Это навязанная услуга, которую Россети никогда не делают, операторы сами занимаются переподвесом. Эта услуга составляет до 90% себестоимости по методике Россетей.  Что позволяет вести против Россетей борьбу в судах и в ФАС.

В регионах суды охотно эту логику принимают и много судов в регионах выиграно и проверено на уровне региональных апелляций и кассаций. Самая активная борьба происходит в Московском регионе. Тут Россети привлекли дорогих юристов. Привлекают на свою сторону Минэнерго. 

Суды оказываются в сложном положении. С одной стороны, с юридической точки зрения все очевидно - нужно вставать на сторону Операторов. С другой стороны есть сильное административное давление.  В результате, суды часто склонны ставить такие дела на паузу. Ждали решение Верховного Суда.

Недавно закончилось дело "ПВОНЕТ", которое было в Верховном Суде оператором связи проиграно. К сожалению, это был неудачный для операторов пример, когда оспаривался действующий договор. Чаще удается отстоять позицию операторов связи, когда речь идет о навязывании новой цены в допсоглашениях. Оператор связи настаивал на незаконности тарифов, что неправильно.

Есть опасения, что суды в регионах будут ориентироваться на это решение Верховного Суда. По крайней мере в тех случаях, когда судья не хочет вникать. Если же судья хочет вникнуть, то есть возможность донести до суда позицию оператора связи.

Кроме того, дело "ПВОНЕТ" Верховый Суд к себе не забирал. ВС по сути написал отписку в данном случае.

Ордерком провел анализ судебной практики по стране и готов приводить судебную положительную практику. И часто это позитивно воздействует на суды.  По крайней мере, в тех случаях, когда суды не находятся под серьезным административным давлением. Особенно в регионах. Шансы победить есть, и они – хорошие.

Глобальная практика такая - если не бороться, то Россети активно повышают тарифы. Если бороться, то по крайней мере у Россетей снижаются аппетиты. 

Опасная тенденция: московская практика созданная ПВОнет и РамсвязьИнвест, расширяется по другим филиалам Россетей. Операторы связи на Урале и в Приволжском федеральном округе получили уведомления о том, что теперь Россети будут брать деньги за каждый кабель. С НГ по всем Филиалам изменена Методика, ЗВОЛС исключен из тарифа. Получается, придется заново анализировать Методику, истребовать калькуляцию... Это может идти бесконечно.

Совет - строить свои Опоры или зарывать кабель в землю на гос. мун.землях. Это может быть бесплатно ( каждый субъект принимает свои правила в данной области и члены АМОР имеют полную картину).

Сейчас бороться будет сложнее. 

Есть распоряжение Мишустина о том, чтобы снизить тарифы и стабилизировать правила доступа. Пока по этому направлению движения нет. Была единственная встреча, на которой федеральные операторы связи не явились, а были лоббисты энергетиков, которые запугивали операторов и заявляли, что ассоциации представляет ничтожную часть населения. 

В последних судах на стороне Россетей активно выступают представители Минэнерго. Хотелось бы, чтобы и наш регулятор помогал нам в судах..

Какие альтернативы подвесов на опорах Россетей? Альтернатива есть. Это установка своих опор. Сейчас Ассоциация АМОР плотно прорабатывает правые и технические вопросы установки собственных опор.

Про перспективы дальнейшей борьбы с Россетями мысли имеются, но они не для публичного обсуждения.

Как мы пришли к решению попробовать C-Data вместо привычного Eltex

Eltex определенно отличное оборудование в области GPON. Годами проверенный вендор с отличной поддержкой и качеством. Но и у него есть свои нюансы:

• «Вендор лок» - (от англ. vendor lock-in) — это ситуация, когда клиент оказывается «заперт» на использование продуктов, услуг или технологий одного поставщика (вендора). Простыми словами: Вы можете использовать только терминалы Eltex (ONU). Можно решить эту проблему, например, докупать лицензии на каждый сторонний терминал или внести изменения в OLT. Но все это стоит денег и имеет некоторые сложности.
• Отсутствие интерфейса из коробки. Все-таки должен быть простой web-интерфейс для операторов клиентского отдела, чтобы в любой момент времени из любой точки можно было зайти по телефону.
• Более высокая цена по сравнению с другими производителями OLT.
• Доступность покупки оборудования Eltex. Нет такого, что зашел в любимый магазин NAG и купил, все что нужно и через 2 дня все у тебя. Вечно нужно заказывать, узнавать, ждать.

Сразу хочу обозначить, что это мое оценочное суждение, все эти минусы решаемы, но я как представитель небольшого оператора связи хочу заметить, что компания C-Data заняла нишу мини OLT.

Первое знакомство с OLT C-DATA FD1602S-B1

Первая мысль – «то что надо» и вот почему:

• Маленький размер, можно разместить в любой необслуживаемый узел, для «быстрого захвата». Еще один плюс против Eltex.
• Наличие дополнительного входа питания 12V, можно использовать более эффективные варианты UPS.

Спорные моменты:

• Wi-Fi модуль, реквизиты входа наклеены на крышки. Для чего это сделано не понятно. Есть предположение, чтобы ускорить знакомство с веб интерфейсом и акцентировать на этом внимание.
• ЖК-дисплей. Зачем?! Пощелкал, сделано не плохо.

Дизайн корпуса на твердую 3, есть над чем работать. Самое главное наличие SFP+ порта, для подключения на 10G. В целом не плохо, в совокупности супер!

Тестирование совместимости с терминалами Eltex

Итак, имеем существующую GPON-сеть, где мы в теории убираем Eltex станцию и ставим C-Data. На сети установлены разные ONU, все возможные модели Eltex NTP, NTU. Важно отметить, что терминалы настроены в режиме роутера PPPoE. Могут попадаться любые версии прошивок, которые выходили в последние 5 лет.

Спустя несколько дней тестирования, подбора вариаций получились следующие выводы:

• Работают все модели терминалов Eltex NTU на OLT C-Data в режиме роутера или бриджа. Независимо от прошивки или каких-либо ревизий.
• Не работают все модели терминалов Eltex NTP.

Результаты неутешительные, но вполне оптимистичные. Так же нужно учитывать, что модели NTP морально устарели еще несколько лет назад. На нашей сети их осталось максимум 10%. Поэтому перед переходом можно обеспечить абонентам замену на более мощные новые терминалы.

Первые впечатления после запуска

В день «икс» несмотря на все наши опасения, после замены Eltex на C-Data, все замечательно «стартануло». Абоненты, узлы, запитанные как в режиме бриджа, так и роутера поднялись, все заработало идеально. Станция работает значительно живее и быстрее, чем предыдущая Eltex.

Немного конфигурации

Для простоты понимания используем три vlan’а:

• 4001 – тегированный, сюда включаем все onu в режиме роутера, т.е. подключение создается непосредственно внутри самого терминала, который в свою очередь производит NAT, DHCP и т.п.
• 4002 – тегированный, используется для onu в режиме бриджа. Терминал у нас в режиме медиа конвертора.
• Untag – не тегированный vlan, оставляем для совместимости с различными другими терминалами.

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

Отключаем автоматическую регистрацию терминалов:

Включаем автоматическую подчистку таблицы ONU от старых терминалов (неактивных 180 дней):

Прописываем терминал Eltex NTU-RG в режиме роутера.

Важный момент: по умолчанию вся серия NTU-RG (не путать с NTU-1) может работать с Cdata, только в режиме роутера. Если вы хотите передать vlan напрямую на порты, необходимо самостоятельно произвести настройки. Зайти на роутер, добавить сервис bridge и в mapping проставить необходимые порты.

Прописываем терминал Eltex NTU-1 в режиме bridge. А также аналогичные ONU ZTE/Huawei и т.п., в том числе xPON.

Напомню, что терминалы xPON — это устройства, поддерживающие одновременно две технологии пассивной оптической сети GPON и EPON. Такие терминалы — универсальные абонентские устройства, которые могут работать в обоих вариантах PON-технологий.

Прописываем старые совместимые терминалы в режиме bridge. Например, GPON ONU Ericsson T063G.

Подобные терминалы настолько устарели, что некоторые организации избавляются от них за самовывоз. Тем не менее результаты тестирования GPON Cdata показали, что OLT поддерживает их.

Нюансы

OMCI работает не совсем стабильно, видимо есть нюансы в совместимости. Проблем в отправке «перезагрузки» не наблюдалось. А вот сброс роутера на заводские настройки не работает. Удаленная перепрошивка роутера – бывает работает, а бывает нет.

Важный нюанс, если ранее вы назначили на какой-то порт роутера отдельный vlan на Eltex (так называемый profile ports), то часть настроек вшивается прямо в терминал. И теперь этот порт не будет работать с Cdata, пока не сбросить терминал, а сбросить терминал с OLT может и не получится (только физически).

Итог

На рынке появилась отличное оборудование. Теперь есть минимальный опыт использования OLT Cdata вместе с ONU Eltex на уже построенных сетях с использованием терминалов в режиме роутера. Благодарю всех, кто принимал участие в поисках решений на возникающие вопросы. Отдельная благодарность команде SHOP.NAG: менеджерам, службе поддержки и техническим специалистам, они нам сильно помогли.

Удалось собрать ответы по 65 провайдерам. Порядка 40 удалось опросить голосом и 25 ответили текстом.

Понятие "маркетинг" трактуется очень широко, поэтому респонденты говорили об огромном количестве сущностей. Для кого-то в фокусе вопросы сервиса, для кого-то запуск домофонии, для кого-то - как наладить CRM-маркетинг, ну и так далее. По ощущениям получился полный срез интересов обобщенного провайдерского комдира. Можно увидеть матрицу вариантов, в которой играет отрасль.

С другой стороны, я ставил вопрос именно о приоритетах. Я хотел понять: где для собеседника важно получить результаты? Делать одновременно все - нереально. Какие-то вопросы должны быть в фокусе. Поэтому отвечающий говорил о довольно небольшом количестве вещей - тех, которые важны именно для него.

Раздел “Динамика и ARPU”

Приток на старых территориях. 

Ответы зарегистрированы такие

Интересен маркетинг переключения клиентов с федералов и демпингующих конкурентов в тех же населенных пунктах присутствия и на более высокие тарифы.

Видим сокращение кол-ва притока новых абонентов. 

Как привлечь абонентов в старом жилом фонде, когда на территории еще агрессивно работает МТС?

Анализируем причины подключений. видим разрыв в сервисе (конкурент не может починить аварии, к нему сложно дозвониться). 

Интересны способы, которые позволяют выцепить клиента - что клиента сподвигает подключаться, схемы поведения.

Проблема понятна. Старые территории для любого провайдера - это ядро базы. Задача получения абонентов со старых территорий объективно важна. 

Захват новых территорий.

Это в фокусе операторов, которые пытаются в текущих реалиях строиться или думают об этом.

Как увести абонента когда ты зашел в МКД пятым?

И как заходить в МКД, где уже есть другие провайдеры, либо эта игра не стоит свеч ?

Как набрать 25% доли рынка за 3 года ?

Зашли в МКД, непонятно как получить абонентов (объяснить клиентам чем гепон лучше эзера и почему за это нужно больше платить).

Как захватывать рынок (показать свои преимущества), если зашел в поселок третьим или четвертым?

Лично мне непонятно, зачем строиться, если у тебя нет четко отработанной схемы захода в территорию пятым? Это же омертвление капитала. Вы засадите деньги в стройку, получите рост операционных расходов, растянутые коммуникации, рост нагрузки на саппорт, а ради чего?

С другой стороны - провайдеров понять можно.  Выручку-то наращивать надо. Если привыкли строиться и если других идей нет, то что делать?

Вот у этих респондентов в фокусе проблема оттока и тесно связанная с ней проблема демпинга.

Увеличение оттока в связи с ситуацией в мире, демпингом конкурентов. 

Важно продление срока жизни абонента. Борьба с оттоком,  особенно при индексациях.

Есть отдел заботы о клиентах (внутри коммерческой службы). Фокус - негатив в сервисе, система удержания или возврата. Набирали из лучших спецов в коллцентре.

Как удержать базу на фоне демпинга монополистов?

Волнует демпинг со стороны конкурентов.  250 р в месяц в частном секторе.  Заходят 2-3 месяца активной деятельности, роняют рынкок. Потом исчезают, но клиенты уже психологически настроились на то, что интернет должен стоить не 1000р, а 250р (частный сектор).

Люди уходят из-за того, что устарел роутер, и другой оператор выдает роутер. Выдавать всем новые роутеры мы не можем, а конкуренты могут.

Федералы демпингуют.

Демпингуют сотовые операторы, демпинг + конвергент, опасаемся оттока.

Самое актуальное - профилактика оттока.

Агенты федералов проводят ультраагрессивные обходы ЧС с демпингом. Но есть хороший возврат с  федерадбных операторов на основе качества сервисного обслуживания. Интересуют идеи профилактики. Демпинговать федералам уже некуда.

Федералы  демпингуют.

Крупный сотовый оператор очень низко продает - тарифы в два раза дешевле  чем у нас + 3 симки.   Есть люди которые уходят.

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

Очень похожий сущностно ответ, но я его выделил особняком. Как реагировать на демпинг?

У нас один местный провайдер в городе начал кампанию по удешевлению тарифов, вплоть до билбордов и экранов везде повесили рекламу об этом. Мы сейчас думаем как отвечать, потому как опустить средний чек на 30%+/- нам прямо больно будет, ибо и так грубо говоря сидим на минималках, а с таким подходом - хз как быть. 

То есть, в игре "передемпингуй товарища" участвуют не только федералы, но и местные операторы. Я, честно говоря, не понимаю: на что люди рассчитывают? Тут куча головняка - неостановимый рост зарплат и кадровые проблем, СОРМ с жуткими штрафами. Затраты на инфраструктуру прут, как не в себя. Куда еще и демпингом заниматься? Но ведь занимаются же.

А как на такое реагировать? Ронять цены самим? Это суицид. Не реагировать? Отток и тоже грустненько

Вопрос....

Три респондента делают акцент на проблеме переездов:

Удержание абонентов при переездах.  Как заинтересовать, чтобы нас перевозили? Особенно если заезжает в дом, где нас нет.

Клиенты отключаются из-за переездов, а новые абоненты привыкли к федералам, подключаются не к нам.

Люди уезжают из нашего городка, обычно в областной центр. Как наладить продажу лидов?

Мне нравится этот вопрос. Он хорош тем, что делается правильный фокус. Не секрет, что основной причиной отключений является вовсе не демпинг, а как раз социальная динамика. Люди умирают, люди переезжают в другие города. На социальной динамике вы неизбежно теряете порядка 1% клиентов в месяц. Но квартиры же не стоят пустые? Кто-то же туда въезжает? Как сделать так, чтобы этот кто-то подключился к нам, а не к привычному крупному оператору?

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

Как уговорить нового жильца, который ничего раньше о вас не слышал, попробовать вас, а не подключиться к понятному федералу?

Очень хороший вопрос. С серьезным экономическим значением.

Ответы в группе "тарифы".

Как сделать привлекательными дорогие тарифы?

Как  продавать дорогие тарифы?

В фокусе тарифная стратегия.

Надо учить людей пользоваться дорогими тарифами.

Вопрос тяжелый, но перспективный. Если вдуматься, то на практике люди действительно далеко не всегда выбирают самое дешевое. Зачем-то же люди покупают мерседесы, хотя могли бы ровно с тем же успехом кататься на хендай солярисах. Однако, наша отрасль насмерть привыкла к ценовой конкуренции. Может быть, действительно мы слишком долго варимся в своем котле и нам нужны свежие маркетинговые идеи? Как-то же предприниматели не боятся открывать дорогие кофейни, хотя рядом тот же кофе можно купить в два раза дешевле? Почему-то магазины не боятся продавать дорогие сумки, хотя ровно такие же функционально сумки на рынке стоят пятачок за килограмм?

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

В общем, как продавать дороже -  действительно правильный вопрос и хорошо, что есть провайдеры которые над ним задумываются.

Про индексации - вижу два ответа:

Нужно проводить большую индексацию (сильно поднимать цены). Нужен тренинг.

Планируют провести на НДС (+5%).

Кто меня давно читает - не даст соврать. Я давно топлю за индексации. Я вижу в этом системный выход из кризиса для отрасли - нужно просто приучить абонентов, что интернет, как и остальные услуги, регулярно дорожает. Надеюсь, что остальные 63 провайдера, не ответили что планируют индексацию просто потому, что для них это уже отработанная рутина, о которой и говорить не стоит. Собственно говоря, повышение тарифов на 5% - это мы просто отыгрываем потери на закрытии упрощенки. Что мило, но не решает наших вопросов. А вот как повысить тарифы на 30% и при этом не потерять базу - это действительно хороший вопрос.

Блок "Удержания и возвраты".

Тут ответы зарегистрированы такие:

Как возвращать?

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

Очень много бегунков - которые бегают между операторами из-за акций.  Как работать с этой аудиторией?

Удержание и возврат - большая тема, если в ней серьезно разобраться. Взять хотя бы возвраты. Если посмотреть свои CRM, сколько людей отключилось и придумать как их вернуть - то это же большие деньги. С небольшими инвестициями, потому что инфраструктура к ним уже построена.

А удержание у провайдера должно работать очень надежно. В нынешних реалиях разбрасываться абонентами преступно. Удержать старого гораздо дешевле, чем привлечь нового.

Раздел "Базовый маркетинг"

Пачка ответов, которые я условно отнес к группе Бренд.

Задача - укрепить лояльность к бренду.

Конкуренция с крупняком. У потенциальных абонентов есть недоверие, что у нас маленькая компания и может закрыться. Страшно такой компании заплатить 6000 за подключение. Есть местный крупный регионал, который тоже подключает. Типа компания большая и более стабильная. Кому-то это важно - подключиться к надежному. Нам нужно вложить в голову идею. что мы " мы работаем быстрее, потому что мы ближе". Как убедить людей, что мы ближе и быстрее?

Как отстроиться от федералов?

Стоит задача перед маркетологом - прокачать бренд, прокачать узнаваемость.

У нас три бренда под три ЦА (молодежь, семейная, крутые мужики). Для каждого бренда свое продвижение. Находится аудитория, которая ищет именно этого. За счет этого и выживаем.

Задача продвижение бренда.

Что можно предложить клиентам и как это подсветить? Может какие-то экологическую повестку? Сейчас вкладываем в каждый договор открыточку с аромасаше?

Если мы хотим не терять абонентов от атак федералов и хотим продавать дороже федералов, то получается, как ни крути - нам нужно как-то ковать свой бренд. У провайдера должно быть свое лицо, какая-то идея и это должно быть для жителей достаточно привлекательно, чтобы они были готовы за это платить больше и не уходить на федералов.

Один ответ в группе Узнаваемость.

10 лет работаем - а люди про нас не знают.

Да, это непорядок.

А кстати, вы уверены, что вашего провайдеры жители территории знают? А почему вы в этом уверены?

Еще несколько ответов, где респондент фокусируется на вопросе "лучшести" (чем мы лучше конкурентов?).

Как подсветить клиентам - что у нас живая техподдержка?

В маркетинге главная задача сейчас - отстройка от федеральных операторов.

Ищем УТП для b2c - пример хорошего УТП это конвергент. 

Как донести до клиентов конкурента, что у нас качество выше?

Иногда удается сыграть на проблемах с качеством у ростелекома. Иногда у ростелеком все в порядке с качеством и тогда непонятно на чем играть.

Вопрос правильный и фундаментальный. Это ключевая задача маркетолога: понять, чем мы лучше конкурента, сформулировать это в доходчивых формулировках и донести до аудитории (включая сотрудников).

Есть ответы, где респонденты отмечают важность фокусировке на определенной Целевой аудитории (ЦА).

Ищем выходы на молодежь. К Дню области проводим квест-игру для молодежи по городу.

Формирование нового образа - работа на смену ЦА (ее омоложение).

Методы анализа ЦА. Выделение групп ЦА среди населения. Выявление приоритетов ЦА. Построение рекламы на базе потребностей ЦА     и донесение до ЦА

Хотим проработать аудиторию студентов

Тоже очень интересное направление мысли. Обращаю внимание, что традиционно телеком не мыслит в терминах ЦА. Для нас ЦА - это любой житель дома. Или не житель, а допустим устройство (банкомат, шлагбаум, камера). Нам в принципе все равно кому продать провод с интернетом. Для нас ЦА всегда равнялось всему социальному срезу. Это не характерно для других бизнесов. Другие бизнесы привыкли к тому, что их продукция нужна не всем на свете, а определенным группам населения, на которые соответственно нужно фокусироваться. Может быть пришло и провайдерским маркетологам начать думать в терминах ЦА?

Выделяем, допустим, группу "пенсионеры" и бахаем какую-нибудь рекламу в собесах, пилим какие-нибудь коллабы с патронажными сестрами etc. Потом выделяем другую группу - скажем, автовладельцы. Пилим какой-нибудь продукт (камеры во двор, камеры на перекрестках), мутим какие-нибудь коллабы с местными автоцентрами в стиле "для абонентов “ромашка телеком скидка” на регулярное техобслуживание в центре “ваши шины".

Ну и так далее. В общем, есть о чем подумать

Следующая группа "абоненты которым не особо нужна фикса".

Есть маркетологи и продажники для которых это боль. Тут у меня две подгруппы.

Подгруппа  "то пользуются, то не пользуются".

 есть абоненты, которые то пользуются то не пользуются

Подгруппа  "хватает мобильного интернета".

Есть такие абоненты, которым хватает мобильной связи и им GePON не нужен.

Что тут сказать. Вопрос серьезный, особенно в ЧС. Ты, допустим, упарываешься, тянешь трассу до поселка, На что-то рассчитываешь.  Даже кого-то подключаешь. Но вот в этом поселке сотовый оператор ставит свою вышку и досвидос. Что с этим делать - очень хороший вопрос. 

В МКД это тоже проблема. Куча людей, которые просто приходят с работы и ложатся спать. Им банально хватает интернета с мобильника - непонятно зачем им вообще платить за фиксу ШПД. И чем больше и качественней развивается мобильный интернет, тем от этого хуже фиксе. "Я знал, что рано или поздно мы перейдем и на это дерьмо" (с).

Один из ответивших обратил внимание на важность работы с микрокомьюнити.

В фокусе вопрос - какие микрокомьюнити в городе есть и  как с ними наладить взаимодействие.

Лично мне нравится такая постановка вопроса. Посмотреть, какие есть в городе группы - мамочки, любители аниме, охотники, автолюбители, любители бега -  через какие-нибудь информационные коллабы наладить с ними работу и вот у нас уже предметный ответ на вопрос - чем конкретно мы лучше других. Они не могут доковыряться до мышей. А мы - можем.  И доковыряемся!

Чем конкретно должен заниматься провайдерский маркетолог? Работать партнерку!

Занимаемся коллаборациями с партнерами.

Ведем коллаборации с партнерами.

Рекламные интеграции, коллаборации.

Коллаб с охранными агентствами по ВДН.

Завели отдел по работе с агрегаторами и с партнерами. Есть проекты со Сбером -  в Сбере можно общаться, там не так забронзовели как в Яндексе. Есть позитивный опыт с агрегаторами.

Есть партнерка с местным бизнесом - в ответ они дают сертификаты на свои продукты. Раскручиваем партнеров в своей ТВ в приставке. Разработали приложение, которое дает у партнеров  скидку - скидку клиент получает по домофонному ключу . Партнеры получают показы при загрузке приставки.

Партнерка это хорошее направление мысли. Малобюджетно, есть определенный эффект, работает на стратегические задачи. Заниматься партнеркой нужно.

Раздел "Реклама, офлайн"

Весьма популярная группа  - "акции". Как маркетологи формулируют свои вопросы в этом разрезе?

Хотим разработать программу лояльности; хотим приучить абонентов подключать автоплатеж.

Нужно как -нить поднять тему акционных предложений. потому что куда ни плюнь, везде одно и то же барахло. Нет оригинальности никакой и идей по привлечению новых и удержанию старых.  Одни дешевые цены на 3-6 месяцев да приведи друга

Работа в городах где нас рекомендуют - на постоянку акции приведи друга. 

Задача рост числа участников бонусных программ в мобильном приложении и соц сетях.

Как в этом году перезагружать абонементы (каким контентом набить)? (речь идет об бонусах для абонентов, которые готовы платить за год вперед)

Надо пилить актуальные маркетинговые акции:

- школьники 

- люди возвращаются с дач

Какие акции для привлечения работают?

Какие акции работают?

Акции - дело хорошее. Это всегда инфоповод, какая-то шумиха, возможность сподвигнуть кого-то подключиться. А как сделать акции эффективными или хотя бы оригинальными? Хороший вопрос.

Я проводил опрос в августе, а уже в августе хорошие девочки думают о том, что у нас скоро "Новый год"!

Думаем какие делать подарки партнерам.

Календари!  Дизайн - было все. Нужны новые идеи.  Сейчас юбилей города - надо привязаться.

Надо делать подарки, сувениры.

Новый год, вопрос как бы рутинный, но тем не менее важный. Вот чем хорошо быть маркетологом - так это тем, что у тебя все время праздники! А чем плохо, так это тем, что праздники не твои - наоборот, ты должен кого-то обеспечить хорошим настроением, да еще и лидов как-то вытащить. 

Участия в городских мероприятиях, дворовые праздники. 

Для нас год юбилейный. Нагрузка колоссальная.

Ищем выходы на молодежь, тут к Дню области проводим квест-игру для молодежи по городу.

Следующий год для компании юбилейный. Что можно сделать?

Участвуем в праздниках района.

Много участвовали в городских мероприятиях.  Мало затрат, но эффект норм.

Я вижу тут задачу маркетингового кружка, чтобы как-то совместно напрячься и еще раз обратить внимание на различные схемы и механики по сбору лидов. Устроить праздник не проблема, вопрос в том, как сделать процесс выгодным для провайдера.

Вот еще интересный ответ. Тут речь идет о бонусной программе. Тут даже не вопрос, а рассказ о том, что люди делают. Опыт интересный поэтому вывел особняком.

У нас есть бонусная программа. Клиенты при каждой оплате интернета получают бонусы. На бонусы можно потом получать от нас брендированный мерчь. Мы купили лазерный гравер и сами брендируем всякие штуки с озона. В принципе клиенты могут отоварить бонусы не нашим мерчем, а сертификатами от партнеров.

Крутая идея. Напихать в процесс потребления интернета всяких точек, где можно лутануть бонус и малобюджетные схемы, как потом абонент сможет бонус реализовать. Такая геймификация процесса потребления нашего интернета. Круто.

Пачка вопросов по поводу наружки.

Выросла в цене офлайн реклама (билборды, экраны).  Непонятно как влияет на продажи, но люди их видят.

Как защитить рекламы от срывания (на столбах электриков)?

Делаем экраны по городу.

Хотели послушать коллег про тенденции в наружке - наружка работает или нет. Очень подорожало.

Баннер на въезд в город - как увеличить эффективность?

Делаем таблички в парке.

Вопрос хороший. Наружка действительно заметна, но ее эффективность это вопрос. А цена - существенна. Заниматься ли и если делать, то как?

Ну и конечно не забываем о том, что  нас по факту кормит. Реклама в подъездах.

В фокусе пассивная реклама. Наклейки, таблички. 

Реклама в подъездах наклейки, таблички. 

Пробовали нанимать людей на расклейку, но много кидают, приходится самой клеить.

Делаем спам.

Раскидка неэффективна, раньше было раз в полгода, теперь думают вообще отказаться.

Задача  придумать форматы! качественная реклама в новых домах, но не листовки. Новостройки, обычные дома, где жители поддерживают чистоту.

И по сути тоже самое, но почему-то выделил как отдельный крик души

Как рекламироваться в домах, где не дают вешать рекламу?

Действительно, как? Очень обидно бывает, стоит такая элиточка, красивенькая, квартирки там богатые. Кабель в доме есть, а абонентов нет. Все через старшую по дому, а она вешать ничего не дает и хоть плачь.

Один отвечающий упомянул в качестве рекламного канала местную радиостанцию.

думают над эффективностью радио

Еще двое отвечающих провели ребрендинг и перед ними сразу встала гора работы.

Сотрудничаем с агентством по поводу разработки наружки.  Есть задача провести ребрендинг, освежить фирстиль

Провели ребрендинг - идет переработка всего визуала (вывески, плакаты)

Я лично, к идее проводить ребрединг, отношусь с существенным скепсисом. Не особо понятно, как это повлияет на деньги, а ресурсов отожрет прилично. Но, наверное, бывают ситуации, когда ребрендинг назревает. Тогда приходится.

Напоминаю - я ставил вопрос так "Какие задачи являются для вас сейчас максимально приоритетными?". Многие ответили в том духе, что ищут новые каналы продаж.

Придумать новые методы привлечения абонентов (уже не знаем чем их удивлять)

Альтернативные каналы продаж (кроме прямых продаж) 

Интересны новые и эффективные каналы продвижения 

Поиск каналов продвижения - какие каналы работают

Что работает?

Стоит задача качнуть пассивные каналы

Тут, как мы видим, задача поисковая. Старые каналы продаж нужной отдачи не дают, и есть мысль, что возможно есть какие-то каналы продаж, которые отдачу дадут.

Ой не факт.... коллеги, возможно мы просто выжрали рынок? Ясно, что в 2025 так, как в 2012, заявки переть не будут. С другой стороны - кто ищет каналы продаж - можете внимательно просмотреть эту статью. Похоже, тут перечислено все, до чего дотянулась провайдерская мысль. Можно выбрать себе что-то по вкусу и потестировать.

Раздел  “прямые продажи”

Тут разные аспекты, связанные с прямыми продажами, и вот какие вопросы провайдерские специалисты перед собой ставят.

Агенты и прямые продажи.

Хотим построит прямые продажи у себя. У конкурента по слухам, была девушка, которая разрулила крутые прямые продажи в пригородах, но она ушла в другую отрасль

Агенты эффективны только на старой территории, где нас все знают. На старой территории агенты дают отдачу. На новой нет.

Ведем коллабы с местными школами, чтобы создать агенту узнаваемость.  Важно, чтобы когда агент пришел, потенциальные абоненты должны заранее знать о том, что мы зашли в поселок.

Откуда брать агентов прямых продаж?

Многие сомневаются (и справедливо) в том, что прямые продажи сейчас эффективны. Но вот, по крайней мере, два ответа связанные с темой почему агенты эффективны, а прямые продажи работают.

Почему агенту удается на нас перетащить? Или у конкурента есть проблемы с качеством. Или нам удается сыграть на цене (у нас дешевле), Ну и есть много людей, которые просто хотят попробовать что-то новое, при визите агента вспоминают обиды на старого. У агента есть инструмент - крутые акции. Задача агента разговорить клиента и убедить его, что кроме забронзовевших федералов, есть мы - активные местные игроки. Людям это нравится.

Хотим освоить технологию - продажи через опросы. Сначала ходим и разбираемся что у клиентов болит, потом продаем.

Как минимум, один комдир озабочен вопросом "что дальше?".

Куда девать команду активных продажников, когда будет заморожена стройка?

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

Раздел “сегменты по типу территории”. 

Дальше пачка ответов была в терминах сегментов по типу территорий.

Вот что говорят про частный сектор.

Ключевой вопрос для нас сейчас - как увести абонента в частном секторе?

Частный сектор растет.

Есть задача продвигаться в ЧС. Надо выйти на 10% проникновения.

Главная проблема в ЧС - конкуренция с мобильным интернетом.

Важны продажи в частном секторе. Думаем -   какие услуги могут сподвигнуть жителя ЧС подключить фиксу хотя бы на какие-то деньги.

Частный сектор развивается.

Частный сектор по нашим наблюдениям последний крупный слабоосвоенный сегмент. Там есть рост.

Вот что провайдерские маркетологи говорят про МКД

Жуткая проблема с МКД. Построили квартал МКД с gepon а абонентов нет. Там все сидят на старых эзернет провайдерах, непонятно как сподвигнуть перейти.

По старому МКД отток равен приток.

В МКД все стабильно, высокое проникновение

Как минимум, один отвечающий выделяет в МКД в качестве особого интереса  Общежития.

Ну и разумеется, провайдеры алчно поглядывают на новостройки.

Подключение Новостроек - интересно.

В новостройках ЖК главный вопрос -   как уйти от демпинга большой четверки.

В новостройки активно заходим. В регионе  идет стройка. Заходы в новостройки, кладем свои провода. Активно мониторим стройки - ищем котлованы. Лезем вперед ростелека. Инфраструктура кабельканалы свои.

К новостройкам высокий интерес .

По новостройкам два вопроса:

 - Как работать с УК в новостройках в связи с новым законом?

 - Что можно предложить для УК застройщика?"

Новостройки есть и это интересно

Высокий интерес провайдеров к новостройкам логичен и оправдан.

Раздел дополнительные услуги 

Самая большая группа - домофония. 

То ли я в опросе делал на это фокус, то ли это и правда самый мощный тренд. Но, тем не менее, ответов по домофонии правда много.

Умный домофон -  как продвинуть эту услугу в МКД если жильцам это не нужно. В нашем городе домофоны бесплатные. Умных домофонов жители не хотят. Как качнуть жителей?

Интересен маркетинг услуг умной домофонии.

Окупаемость умной домофонии.

Домофония важна.

Домофония - интересно

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

Стоит задача построения коммерческой службы с использованием возможностей домофонии

Начинают работать с умной домофонией. Умеют в прямые продажи

Заходим в умную домофонию. Жилой фонд пяти и девятиэтажки

Запускают пилоты, надо продвигать

Домофония - завершаются пилоты. Есть свое приложение

Надо учиться продвигать

Домофонию осваивают

Развернули домофонию - не видят отдачи. Нет прямых продаж

Думают сделать пилот

Домофонию запустили - теперь вопрос - как получить абонентов физиков?

Умная домофония для нас уже рутина

Мобильное приложение есть для андроид  - нужно сделать на айфоне. Переводим на ланту

Умная домофония есть

Думают над партнерством с существующими домофонщиками

Начали работать с росдомофоном. Есть квартал, который можно охватить. Задача максимально эффективно прокачать квартал.

Работа через домофонизацию. Тотальная застройка главного города. Малые города уже закрыты, там домофонию обкатали.

Начали заниматься домофонией в партнерстве с домофонщиками

задача отработать микрорайон с помощью умной домофонии

город покрыт домофонией, надо конвертировать абонентов домофонии в интернет клиентов

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

Следующий блок - видеонаблюдение

Зарегистрированы такие ответы:

Видеонаблюдение хорошо пошло

Как выстроить стратегию продаж по новым продуктам? В частности по видеонаблюдению, которое начали потихоньку запускать в этом сезоне

Есть задача продвигать видеонаблюдение

Как развивать видеонаблюдение в частном секторе?  Люди съезжают с дач - будут ли пользоваться ВДН?

Берут мало. Что делать непонятно.

Ставим 4-5 камер на значимых перекрестках - активно пиарим. Хотим закрепить в головах жителей города идею -  "видеонаблюдение = наш провайдер"

Видеонаблюдением занимаются

Видеонаблюдение есть

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

Несколько ответов по КТВ. Честно говоря, КТВ не моя тема, я в этом ничего не понимаю, может поэтому не в фокусе опроса. Тем не менее несколько раз речь про КТВ заходила.

КТВ хорошо развит.

40% проникновение  - все хорошо.

Монополисты по КТВ, есть свой канал.

Наверное, это моя ошибка как маркетолога - недооценка КТВ.  Если есть КТВ и тем более если есть свой канал, то тут прямо скажем есть чем позаниматься.

IPTV

Я считал тему уже давно пройденной. Тем не менее есть даже провайдеры, которые запускают IPTV вот прям сейчас  - в 2025м году.

Есть задача продвижения телевидения среди абонентов.  Смотрешка, ТВИП.  moovi ради бесплатной федералки

IPTV есть

проблема -  люди меньше покупают ТВ (и вообще смотрят)

Запустили свое IPTV 

Запускаем IPTV. Куча вопросов -  тарифы,  каналы и главное -  как   не допустить канибализации со своим КТВ на котором нормально зарабатываем

Добавили услугу свое ИПТВ + есть смотрешка

В общем, на IPTV важно обращать внимание. Во-первых - какая-никакая, а допмонетизация. Во-вторых, IPTV - это бесконечный источник контента для соцсетей.  Пиарим в соцсетях IPTV - и автоматически решаем важную задачу - как набить провайдерскую соцсеть чем-то прикольным. В третьих, допродажа IPTV прокачивает коммерческое мышление у коллцентра, отдела продаж. Хоть какой-то движ, чтобы не скатываться в совсем уж отдел оформления тарифов.

А вот свежая темка в допуслуга подъехала. MVNO

Раньше не было такого. А сейчас прям несколько провайдеров запустили. Ну или думают в этом направлении (спасибо федералам продавцам конвергента - тут тяжело не задуматься)

MVNO интересно

Заключили договор с МТС по конвергенту. Но дело не идет. Нужна схема продвижения конвергента, чтобы привлекать новых абонентов с помощью конвергента

подписали договор с мегафоном по конвергенту, надо продвигать.

Запустили MVNO.  Как его продвигать?

Тут IMHO - самая большая интрига в условиях предоставления. Мы на этом MVNO зарабатываем или нет? Нам выгодно его продавать?

Если выгодно, то это одна история. Если невыгодно, то другая. 

В первом случае его надо так продавать, чтобы продать. А во-втором случае, надо вокруг этого раздуть пиар шумиху, но так все обставить, чтобы случайно не продать.

И совсем свежая струя. Кто-то начал задумываться над продвижением платного контента. Цитирую:

Большие предоставляют дополнительный контент - по подписке. Вопрос - как региональным провайдерам собрать свой пакет с контентом. Важно, чтобы мы не теряли АРПУ.

Хороший вопрос, если честно. Всякие гадские яндексы и сбербанки строят свои экосистемы и зарабатывают на контенте, особо не напрягаясь. А мы тут стекловату нюхаем, из последних сил тащим кабло по тайге, а маржи все меньше и меньше. Непорядок.

А вот это - одна из моих самых любимых услуг, которая, судя по опросу, адски недооценена провайдерами (в разрезе маркетинга). Компьютерная помощь.

И она бы наверное вообще бы не всплыла, если бы не история с блокировкой ютьюба.

Думаем про продвижение роутеров с VPN и партнерка с ноунейм компьютерными мальчиками.

Только один товарищ вспомнил про умный дом.

Интересует продвижение полноценной системы Умный дом и доступной, чтобы максимально клиент был доволен и не думал о переходе. 

Было бы круто, конечно, что-то эдакое навернуть у клиента за его же деньги, чтобы он просто не мог перейти на чужой интернет. Умный дом. Любовь до гроба.

"Если ваша вечеринка не похожа на эту, то даже не зовите меня." (с)

В разрезе допуслуг один ответ меня так растрогал, что я его вынес в отдельную группу, цитирую:

Для меня лично актуальна тема: вывод на рынок новых продуктов. Если данная тема будет затронута, то смогу присутствовать на ваших активностях, в ином случае не смогу участвовать.

Я все понял. Обязуюсь сделать. 

Теория и практика вывода новых продуктов на рынок это действительно прям важный вопрос.

Ну а если серьезно, то есть ответы, которые касаются стратегии работы с допуслугами в целом.

Кросс-продажи при подключении абонентом основных услуг

Продажа доп услуг - телевидение и видеонаблюдение

Хочется больше информации, кейсов по работе с действующей базой ( upsale, продажа комплементарных услуг)

Ключевая задача - это ввести эффективные допуслуги. Что предложить абонентам. чтобы их заинтересовать?

Как выстроить стратегию продаж доп.услуг (Ip tv и видеонаблюдение + возможно домофония)

Все правильно. Если мы говорим про маркетинг (а у нас все-таки маркетинговый кружок), то проблема выглядит так. Интернет это базовая, считай витальная потребность. В 2025 году никому не надо объяснять, что такое интернет и зачем он нужен. Поэтому маркетинг продвижения интернета предельно рудиментирован.

Но как только мы пытаемся продвигать какие-то допуслуги, то первым делом перед нами встает базовая маркетинговая задача - как донести клиенту мысль, что из себя новая услуга представляет и почему она ему вообще нужна (как-то жило он без нее раньше же).

И вот тут начинается сложное. А мы в такое не умеем. Но с другой стороны - 2025 год надо осваивать

Правильно поставленный вопрос - это важный шаг на пути к победе.

По совести  говоря, упарываться и продвигать смотрешку, например, зарабатывая на ней по 100р с абонента - это нутакоэ… надо конечно, но это все-таки не уровень для первого лица.

Другое дело освоить рынок сервисов для УК.

М? Стратегично?

Вот - есть провайдеры, которые думают идти по этому пути.

Что можно предложить УК в плане услуг?

Сделали отдел новых продуктов - СКУД, охрана, пожарка. Привлекли персонального менеджера для УК и старших по дому - они в связке маркетологом продвигают. Сделали кофебрейка для старших по дому - хорошо зашло.

Интересно научиться продавать в МКД дополнительные услуги для здания в целом (коллективные штуки).

Направление важное - будем отслеживать.

Еще есть герои, которые запилили собственное мобильное приложение и теперь осваивают связанные с этим возможности:

Стоит задача -  рост числа участников бонусных программ в мобильном приложении.

Разработали приложение. Клиент получает скидку у партнеров по домофонному ключу. Теперь продвигаем.

Есть свое мобильное приложение, там камеры, домофоны.  Задача продавать платные сервисы - доступ к архиву.

Есть бесплатный функционал  - в домофоне нет видео можно только поговорить и открыть.

И платный функционал - видишь кто звонил, можешь смотреть архив.

Раздел "Вопросы сервиса"

Что только не вешают на маркетологов в маленьких провайдерах :)
Например, некоторых маркетологов волнуют проблемы функционирования техподдержки.

Надо решить платные или бесплатные выезды.   Как не пережать? Но и денег собрать, чтобы абоненты на голову не садились, а то приходится машину за 10км гонять, чтобы роутер ребутнуть.

Надо переработать справочник для абонента на сайте, чтобы клиент мог сам решить максимальное количество вопросов самостоятельно.

Моя любовь  - контроль качества - о сколько я времени этой теме посвятил! Отрадно, что волнует не только меня.

Вопрос, который все чаще встает в моей голове - это контроль качества (и общения и предоставления услуг), вот этот опыт был бы интересен.

А мы помним, что от демпинга федералов можно по факту отбиваться только уровнем сервиса, поэтому что? Поэтому контроль качества наше все.

Ну и еще вопрос, который горячо надеюсь, у большинства провайдеров не стоит. Ночная техподдержка.

Как организовать поддержку ночью для маленькому телекому? У всех конкурентов есть поддержка 24 часа.

Во-первых, ночная техподдержка должна быть обязательно это мастхев.

А во-вторых, если что - обращайтесь к нам. Мы делаем линии ночной техподдержки на аутсорсе.

Казалось бы  - у маркетолога и так забот полон рот, знай успевай разгребать. А тут на тебе - еще Родина порадовала. Замедлили ютьюб

Хорошо, что народ у нас не тушуется, а думает как повернуть негатив в позитив.

Ситуация с ютьюб. Как обыгрывать - можно ли затаскивать на свое ТВ?

Как разыграть в плюс?

Отработка негатива с ютьюб

ЮТЬЮБ 

Есть своя приставка с кинокаталогом - можно ли продвигать в текущих реалиях?

Замедлили ютьюб. Надо что-то объяснять абонентам

Ну… будем надеяться, что абоненты сами быстро разберутся, что с этой неприятностью делать и хоть этого головняка у нас не будет.

Раздел “b2b”

Надобно сказать, что у большинства провайдеров юрлица сильно не в приоритете. Для меня это огорчительно, потому что у меня как раз неплохая b2b-шная подготовка.  Понятно почему - в ринетике основную выручку приносили юрлица. Специфика территории - мы пиратствовали внутри третьего транспортного кольца. Увы, за пределами третьего транспортного кольца юриков считай что нет. Ну, то есть, как нет? Юрики бывают двух типов: это или мелкие магазины на первых этажах и в торговых центрах. Или заводы/промплощадки за городом. 

Однако. Есть провайдеры, у которых в связи с юрлицами возникают вопросы. Поехали.

Раздел бюджетники и корпорации

В этом году развиваем направление СКС и заказных строек (заказчик гос сектор и крупные корпораты)

Надо развиваться по бюджетникам, есть мысли.

Сотрудничаем с городом по видеонаблюдению.

Направление сложное, но перспективное. Сейчас в госсекторе основные деньги. Вопрос - как их взять?

Раздел "магазины, сети"

то что это интересно упомянул только один респондент.

С одной стороны, я понимаю почему так. Мы по юрикам скатились в жуткое нищебродство, когда 2000 рублей с клиента это невообразимо большие деньги. И чего тогда о них думать? При таких тарифах, юрик получается такой просто очень геморройный  физик - и ничего больше.

С другой стороны, все-таки мелких магазинов-то дофига. Как выглядит первый этаж жилого дома? Вайлдберис, красное и белое, салон "красивые ногти", пивная наливайка, и озон.

В принципе, есть чем позаниматься, я считаю.

Раздел "партнерка в b2b"

Ответы такие

нам интересно.

поиск партнеров - юриков, которые могут стать нашими агентами.

Ищем сотрудничество с IT сервисными фирмами. чтобы работать с юриками.

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

Еще несколько ответов я отнес в группу "продвижение в b2b"

Обсуждали тему с отраслевым нишеванием. Ключевая идея - нужно смотреть на юриков не скопом, а отдельно разбираться с магазинами, отдельно с кафе, отдельно с  клиниками etc - подход вызывает отклик

Обновили сайт, сделали лендинг спецом для юрлиц. сделали калькулятор ВАТС.  Стало больше заявок, 

В городе есть бизнесклуб - есть ли смысл вступать?

Хорошие вопросы. Если на вашей территории есть хотя бы пара тысяч юрлиц, есть ради чего напрягаться

Еще ответы, которые я отнес в группу "допуслуги в b2b"

Вот что говорят.

У нас в пакете есть все b2b услуги. Это не удерживает абонента.  У них есть свои айтишники, им от нас нужен только хвост.

Хотим качнуть допуслуги по b2b - интересна отраслевая презентация (отдельные кейсы и презы для каждой отрасли). Услуги ВАТС, Голосовые боты, ЦОД/Колокейшн,  Облачное видеонаблюдение.

Хотим проработать пакетные предложения для юрлиц - инет + телефония + ВДН

Хорошо, что есть провайдеры, которые этим занимаются. От себя добавлю - очень важно, чтобы на допуслуги в b2b был выделен отдельный маркетолог. Это отдельная и очень специфическая область. Я ей много занимался и могу сказать, что тема сложная, ей надо заниматься по серьезному.

Вот эти ответы я отнес в группу "конкуренция в b2b"

Главная проблема - демпинг на объектах недвижимости. Если на объекте недвижимости 7-8 операторов - начинается дурдом.

К счастью, юрики бегут от ростелекома из-за проблем с сервисом.

Последнее - просто прекрасно.

И еще по юрлицам были такие мысли "b2b общее"

Ищем УТП для юрлиц. Чтобы это могло быть?  SLA? персональные менеджеры?

Важный вопрос как поймать юриков на переезде?

Хотелось бы узнать,  как лучше продвигать продукты (интернет, Облачная АТС, облачное видеонаблюдение) в В2В сегменте. Визуал, акции, посты...

Есть заявки, но по ним нет технической возможности. Заказы идут из промзон, где нас нет. Надо  развить партнерства каналами.

Запросов от b2b менеджеров к маркетологам особых нет. По запросу делаем промо материалы. Настраиваем контекстную рекламу.

Повторюсь, на b2b нужен отдельный маркетолог, что делать понимание есть, кому интересно - пишите (телеграм @timhydr). Это, если конечно у вас на территории вообще есть юрлица в существенных количествах. 

Раздел "УК и новый закон о бесплатном доступе в МКД"

Вышел новый закон - провайдеры призадумались - и что теперь с этим делать?

От двух респондентов поступил практически идентичный вопрос:

Как общаться с УК в связи с новым законом?

как работать с УК в связи с новым законом?

Тема сильно не моя. Все-таки, очень юридический вопрос. Я тут брал интервью у Дмитрия Галушко - провайдерская ассоциация АМОР - они в ассоциации эту тему разобрали, подготовили нужные схемы. Кому нужно, пишите мне - вышлю ссылку на интервью.

Раздел “диверсификация”

Тема, которая лично для меня сейчас максимально интересна: возможность создать на базе провайдерского отдела маркетинга свое рекламное агентство, а также диверсификация бизнеса.

Ответы такие:

Есть задача развивать рекламу как отдельную услугу

Можно обсуждать

Может быть

Есть опыт, занимаемся

Интересует тема диверсификации  - какие бизнесы используют подписную бизнес-модель - и можно ли их интегрировать с телекомом

Думаем как монетизировать базу пользователей мобильного приложения.  Пробуем запустить рекламные блоки для местного бизнеса - уже делали  стоматологию, сбербанк. Может быть зарабатывать надо не  на рекламе а на партнерке?

Что я на эту тему думаю - по мне так это самое перспективное, чем можно заниматься.

Будем честны - телеком в тяжелом кризисе. По крайней мере, пока у федералов не закончится демпинговалка, у нас будет грустное положение - затраты непрерывно растут, а тарифы мы толком поднимать не можем из-за наличия конкурирующих, в разы более дешевых, предложений.

И что с этим делать? По хорошему, нужно завязывать со стройкой и искать какие-то другие бизнесы куда можно инвестировать деньги. Вместо того, чтобы упарываться и пятым провайдером заходить в новый поселок, возможно, лучше открыть, допустим боулинг. Катаем шары, продаем пивас, не паримся.

Вопрос только в том - как этот боулинг быстро раскрутить?  А вот если бы у провайдера было бы свое локальное рекламное агентство - то вопрос бы так не стоял. Поэтому, IMHO, максимально разумная стратегия такая - раскачиваем свой рекламный отдел, трансформируем его в рекламное агентство, запускаем другие b2c-бизнесы на той же территории.

Кому такой подход интересен - велкам ЛС (ТГ @timhydr). Я с удовольствием готов участвовать в  таких проектах.

Раздел “кадры”

Перед частью спецов по маркетингу стоят задачи поиска кадров.

Проблемы с кадрами - колл центр, тп. Идет у всех отток по кадрам, а работать никто не хочет. Цель - увеличение штата, сбор резерва.

Возможно, системная проблема, над которой мы бьемся вместе с эйчаром, - некому подключать, кадровый голод))).

Задача - искать сотрудников для своей фирмы.

Мы уже много работали по этой теме. На КРОС-24 я проводил круглый стол, мне кажется мы там с коллегами полностью эту тему разобрали. Кому актуален вопрос поиска сотрудников, посмотрите запись круглого стола.

И вот еще из задач маркетологов - внутренний маркетинг.

Плотно работаю над внутренними мероприятиями для сотрудников, это действительно сплачивает и по-настоящему дружеский вайб в коллективе сглаживает многие вопросы.

Кадровый кризис в стране - это всерьез и надолго. Чем дальше, тем будет тяжелее, и конца края этому не видно. Я готов поверить, что допустим государство возьмет и в очередной раз отсрочит "Яровую". Может быть, федералы перестанут демпинговать. Может быть, ФАС успокоит держателей инфраструктуры. Но тех людей, которых не родили в 1996 году - уже никто не родит. 

За сотрудниками нужно бегать, их сложными способами искать, привлекать удерживать. Это плохая новость.

Хорошая новость в том, что в куче бизнесов все еще отвратительные условия работы, и если вы будете работать нормально, то еще есть откуда сотрудников перетянуть. Переконкурировать если не по зарплате, так хоть  по корпоративной культуре - это вполне реально.

Раздел "интернет-продвижение"

Еще раз повторю важную оговорку про этот опрос. Опрос проводился в свободной форме. Я просто спрашивал разных провайдерских специалистов - что для них сейчас самое важное. Люди отвечали какие-то вещи, которые им первыми пришли в голову (как правило, это неплохо коррелирует с тем, что действительно важно, но гарантии конечно нет). Тут важный момент - если про какие-то штуки ничего не было сказано, это не значит, что их нет. Может быть, допустим, фирма очень хорошо сделала работу в домовых чатах, это для них уже отработанный этап и они теперь думают больше о каких-то других инструментах. То есть то, что про какие-то инструменты не говорят - мы не знаем - там вообще ничего нет или наоборот все так давно и хорошо, что просто  про направление забыли и оно вышло из фокуса интересов.

С такой оговоркой продолжим

Группа Поисковое продвижение (SEO и покупка запросов)

SEO - очень дорого и сложно - выгодней трафик покупать.

делали интернет маркетинг (SEO), но результатов не было - свернули.

Занимаются.

Покупка запросов в яндексе/гугле.

SEO было поверхностно, надо глубже.

Наняли чувака, который оптимизировал рекламу (покупку поисковых запросов).

Навороченное SEO. На каждый дом лендак. продуманные тексты.

хорошее SEO, держимся за счет него

Тут и говорить не о чем. Работа с поисковыми запросами напрямую приносит заявки. Это то, чем точно надо заниматься.

Работа с отзывами

В фокусе работа с негативными отзывами, сейчас особенно в связи с проблемами с Ютуб и с тем, что увеличиваются сроки подключения.

Занимаются.

Надо следить за отзывами, это важно.

Тоже очень важная штука. Сейчас у огромного количества пользователей выработалась привычка читать отзывы прежде чем что-то купить. Поэтому отзывы у вас должны быть - прекрасными. Или продаж не будет.

Таргет

Интересна таргетированная реклама.

Используем таргетированную рекламу.

Делаем таргет при подключении новой станицы.

Занимаемся.

Очень неоднородные территории.  Даже в соседний районах одной области люди реагируют на разные триггеры в таргете.

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

Баннерная реклама

Используем контекстно медийная сеть гугла/РСЯ

Работа с VK

Иногда проводим розыгрыши в ВК

Задача от акционера -  чтобы посетители ВК видели нашу рекламу

SMM менеджер - упор на онлайн. Группа в ВК более живая. Публикуем  фото из жизни компании, делаем  таргет в ВК

Работа в ВК идет хорошо

Напряг новый кабинет в ВК. Перестали пользоваться  продвижением, потому что кабинет стал сложный и  дорого,    неэффективно

Работают городские паблики ВК - это эффективно

У нас развитые соцсети - VK, подписчики идут

Есть

По ВК у нас в маркетинговом кружке был отдельный практический блок. Видимо надо повторить с упором на задачу увеличения продаж

Работа с Телеграм

Из Телеграма пошли заявки.

Стоит задача качнуть телеграм. Он и так хорош, надо лучше.

ТГ есть.

Телеграм развивается - это прекрасно.

Таргетированные SMS (покупают услугу у ОПСОСов)

рассылают жителям таргетированные SMS при подключении нового поселка.

Только один ответ, но может делают больше, а упомянул только один респондент.

Домовые и районные чаты 

Как попадать в домовые чаты?

Сейчас провайдеров ищут в поиске или домовых чатах. Поэтому домовые чаты это важно.

Пытаюсь согласовать бюджет на покупку рекламы в группах.

Нда, народ сейчас домовые и районные чаты активно использует. Попасть туда сложно и мониторить весь этот трафик можно только через специальное IT решение (благо этот вопрос решаем)

Агрегаторы

Сотрудничаем с агрегаторами. Во-первых агрегаторы приносят сами заявки, а во-вторых увеличивают эффективность офлайна (люди видят нас в списках у агрегаторов и это повышает отдачу объявлений в подъездах).

Никогда не думал в таком ключе. Я относился к агрегаторам как к неизбежному злу, которые перехватывают заявки и крадут трафик. Но вот есть провайдеры, которые к агрегаторам относятся сильно теплее.

Работа с chatGPT

активно используем в работе  chat GPT. Чат предлагает сценарии роликов,    как ответить клиенту,   написали чатом  гимн компании

Вау. Пошла тема.

Видеоролики

хорошо идет работа с видеороликами

Видеороликам надо уделять особое внимание. Только они должны быть ультракороткими, в этом сложность.

Я выделил ответы, где фигурировали соцсети в отдельную группу. 

Из ответов непонятно речь идет про VK или ТГ.

Нужны соцсети

Интересны Соц. сети,

Соц. сети - что можно сделать в плане продаж?

Задача рост числа участников бонусных программ в соцсетях

Работа с негативом в соцсетях, как отвечать на сложные комментарии, как отвечать в чатах

Провайдер, который рубится за продвижение своего бренда, должен быть активно представлен в соцсетях. Тут даже вопросов нет. Вопрос исключительно в том, как научиться получать из соцсетей заявки. Над этим будем работать.

Общая ситуация c диджитал

С лета начали рекламу Яндекс.Бизнеса использовать. Пока все на этапе проверок, но как будто бы свой выхлоп это дает. А возможно мы просто начали тратить на рекламу побольше и результаты появились

Надо освоить диджитал  - SEO, директ

Используем Контекст, директ, соцсети, паблики, наладили отчетность - заявки идут

В фокусе работа с подрядчиками по SEO и по директу

Хотим разобраться - какие актуальные каналы рекламы и связи. Какие инструменты сейчас наиболее эффективны для общения как с потенциальными так и с действующими абонентами - email рассылка, смс, соц сети, собственное приложение, мессенджеры и тд

 В целом задачи такие: Улучшить уже работающие каналы (я работаю с онлайном по большей части). По возможности тестируем новые.

Короче, идет работа.

CRM

Делаем сквозную диджитал отчетность + учет касаний

Стоит глобальная задача - выстроить CRM - нужна  прозрачность

Есть такая проблема. Современный диджитал, это в очень большой степени работа с данными. CRM должна функционировать и заполняться данными на очень высоком уровне.

А вот ответы по диджитал, которые я отмаркировал как боль:

Боль - нет проверенных специалистов. Тянут деньги результата нет.

Вопрос - как получить отзыв от работы агентств? Хочется работать с проверенными агентствами, которые уже в каком-то другом провайдере дали результат.

Все скучно, ничего не интересно. Нет бюджета.

Осваиваем яндекс директ - много кликов нет результата.

Общий вывод по разделу диджитал такой: в той или иной степени, провайдеры диджитал занимаются, кто-то освоил лучше, кто-то еще ищет методы работы, но в целом все понимают, что диджиталом заниматься надо, и что это в принципе работает. Хотя проблем тут полно.

Управление маркетингом

Вот пачка ответов которые я отмаркировал "управление маркетингом":

Слабый маркетинг (от формирования дизайна, до продвижения). Понятное дело, что тут всё складывается в зп, но хочется конечно более сильную команду.

Занимаемся базовым маркетингом.  Разработка миссии,  структурируем всю информацию о компании,   готовимся к ребрендингу,  надо все освежить.

Хотим научиться оцифровывать маркетинговые активности и простраивать связь бизнес-целей с маркетинговыми активностями.

Миссия,  цели задачи компании и как это транслируется на компанию на ее поведение.

Вот над такими вопросами люди задумываются, между прочим.

И самый последний блок - который я отмаркировал как "стратегия"

Тут под термином "стратегия" я имею в виду - есть ли у фирмы общее понимание, как она собирается развиваться и за счет чего собирается победить конкурентов.

Понятно, что какая-то стратегия есть у всех. Но тут мне удалось ее вычленить в интервью.

За счет чего можно победить конкурентов?

За счет каких инструментов отбиваются от конкурентов?

     -  хорошая скорость интернета

     -  высокая скорость реакции на обращения

Высокие скорости, хорошее SEO

Приходится модернизировать сети, чтобы давать клиентам больше 100 мегабит.  В связи с этим возникают вопрос.

Как продвигать скорости больше 100 до гига? Надо  после модернизации нужно добавить 25% выручку с дома иначе модернизация убыточна.

И еще - как формулируют стратегию?

Стройка в новых территориях.

Стратегия - освоение пригородов.

Хорошо окопались в якорных городах, щупают частный сектор и допуслуги.

Продавливаем МТС по скорости, крутая экспертиза по WiFi, очень крутое SEO и сфокусированный на ЦА маркетинг.

Запуск новых территорий, активные продажи, праздники, розыгрыши.

Задача строиться -  частный сектор, 

Строить новые поселки.

Сейчас хорошо идут гиговые тарифы. Людям важна скорость, стабильная скорость.  Много облачных сервисов, которые требовательны к скоростям.     Облачные игры - дикие объемы. Роутеры нужны могучие.  Многим нужны скорости для работы - работают с видео.

Прокомментирую.

Строить новые поселки логично в двух случаях.

• если рядом с тобой есть еще слабо освоенные провайдерами территории;
• если ты умеешь как-то "заходить пятым, а выходить первым".

Идея отбиваться от федералов гипервысокими скоростями, мне в принципе нравится, но я не понимаю, что делать с Яровой. Вот, допустим, ты как-то собрал аудиторию абонентов, которым реально нужны адовые скорости и кто потребляет трафик в чумовых объемах. Окупится ли это с учетом необходимости покупать диски, чтобы все хранить?

Идея отбиваться от федералов хорошим сервисом в принципе рабочая, но есть одно НО. А что делать, если в твоем регионе у федералов тоже хороший сервис? Взять хотя бы, к примеру, обыкновенного меня. У меня в квартире Билайн за рубль. За последние десять лет у меня тупо не было ни одной аварии. Я ни разу не обращался в техподдержку.

Разобраться и отладить SEO - это тема. В конечном итоге, наша проблема - это ротация абонентов. Нам просто нужно, чтобы новый жилец с большей вероятностью подключался к нам. Тут возможны три направления перехвата трафика. Или ты перевоевал конкурентов в офлайне (сорвал все вражеские листовки и повесил хорошо свои). Или ты победил конкурентов в поиске (настроил SEO, купил запросы, купил агрегаторов). Или у тебя нечестное конкурентное преимущество в виде домофонии, когда новый жилец мимо тебя в принципе пройти не может. Ну или эксклюзив как-то получить....

Ну или ты как-то акциями, глубокой работой с аудиторией научился перетаскивать к себе абонентов от конкурентов в старом жилом фонде. Типа сидел человек на каком-нибудь домру, например, вроде у него все было нормально, но ты какими-то акциями или имиджем или еще чем-то его выцепил, он к тебе подключился и остался у тебя. И у тебя работает машинка по поиску и перетягиванию абонентов от конкурентов.

Ну или ты уходишь в другие ниши. Осваиваешь другие бизнесы, что-то такое. А старую абонбазу используешь как ресурс капитала для запуска и освоения новых проектов

Какие еще могут быть стратегии в принципе-то?

А, ну жесткий демпинг еще. Как-то утоптать в пол все затраты, уронить тарифы и сидеть ровно. Тоже вариант, хотя и дурацкий - тогда лучше уж продаться.

Ну.... вроде все.

Спасибо тем, кто дочитал, надеюсь было полезно. По крайней мере, мы получили актуальный срез по отрасли.

У нас действует закрытый чат “маркетинговый кружок”, где я собираю телекомовских спецов по маркетингу и коммерции. Кого эти вопросы заботят - пишите мне в телеграм, я вас добавлю (Телеграм @timhydr).

Якутский заказчик захотел установить систему видеонаблюдения на строительных площадках, подключая к каждому шкафу 16 POE-камер. Ни один наш шкаф не обеспечивал такой функциональности, поэтому приняли решение о создании новой линейки шкафов.

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

Ввиду высокой загруженности штатных конструкторов, обратились к конструкторам контрактного завода, на мощностях которого изготавливаются климатические шкафы серии Real. 

Изготовление корпусов и оклейка утеплителем отводилась специалистам контрактного производства, а сборка инженерки и установка коммутаторов - коллегам из дочерней организации НАГТЕХ.

Совместными усилиями за 7 рабочих недель удалось сконструировать и изготовить прототип шкафа. Для понимания удобства сборки и продукта в целом, собрали "инженерку" своими силами. Получился функциональный коммутационный узел с 16 GPOE-портами. Вот только высота и ширина корпуса шкафа составили 82 и 60 см, соответственно. С такими габаритами шкаф на столбе будет как парус на мачте.

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

Инженеры-конструкторы использовали различные комбинации расположения оборудования. Тем не менее, процесс затянулся, совместные мозговые штурмы не приносили плодов и никак не получалось уменьшить габариты шкафа. Через 10 недель с момента старта пришло осознание тупиковости выбранной концепции размещения оборудования. 

Сроки производства поджимали и было принято решение устроить совместный мозговой штурм с инженерами производства. Через 2 недели получили почти такое же решение, как пятью неделями ранее, только с доработками в виде большего количества ступеней фиксации откидной корзины активного оборудования, слабогорючего утеплителя и уменьшения размеров оболочки шкафа на 12 сантиметров в высоту. 

Затягивать с разработкой было уже нельзя. Сроки поставки первого коммутационного узла поджимали. Приняли решение собрать и отгрузить заказчику доработанную версию шкафа и попросить предоставить обратную связь по монтажу.

Почти одновременно с отправкой «первой ласточки» заказчику, мы встретились с главным конструктором на производстве и несколько часов обсуждали, как можно улучшить наше изделие. Результатом круглого стола стал карт-бланш на разработку принципиального нового изделия для обоих производств.

Как известно, даже в одной семье при одинаковом воспитании, не будет одинаковых детей. Так и с инженерами — один ремесленник и делает всё по инструкции, а другой творец, которому претят жёсткие требования.

Оба конструкторских подразделения уловили тренды и смогли разработать компактные коммутационные узлы. Каждый — со своим ви́дением размещения оборудования и со своей спецификой.

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

Для подключения медных патч-кордов от камер видеонаблюдения, коллеги из отдела волоконно-оптических компонентов предложили установить влагозащищённые соединители RJ-45 8P8С. Больше монтажнику не потребуется прокладывать витую пару внутри шкафа — так экономится время на установку и неудобную работу в стеснённых условиях.

Такой результат стал возможен благодаря соперничеству, опыту, а также пониманию конструкторами и инженерами своего продукта.  

На прошедших выставках Securika Moscow и Связь 2024, двухдверный коммутационный узел вызвал заинтересованность потенциальных заказчиков и получил высокую оценку технических специалистов. 

Коммутационный узел доступен с предустановленным одним или двумя POE-коммутаторами.

Возможно изготовление в корпусе из нержавеющей стали для установки в условиях агрессивной среды (морской климат, химреагенты, установка на промышленных предприятиях).

КРОС - это всегда сплав традиций и нововведений, баланс между хорошо проверенными практиками и свежими идеями. Конференция всегда проводится со среды по пятницу и в 2024 году её начало выпало на 22 мая. 

И среда 22 мая, началась в отеле Radisson Collection в Сочи, в полном соответствии с традициями КРОС. 

С 10:00 стартовала регистрация, но участники начали приезжать ещё накануне, поэтому в фойе отеля сразу стало людно. Ближе к обеду машины из аэропорта пошли сплошным потоком, но отработанная годами система регистрации участников работала без сбоев. Участники радовались встрече со старыми друзьями, фотографировались и обнимались с драконом, который встречал гостей на входе. 

С 13:00, также по устоявшейся традиции, начались спортивные состязания для желающих по минифутболу, стритболу и пляжному волейболу. Те, кто не ощущал готовности получить радость от активного движения, осваивали территорию отеля - желающих, сотрудники НАГ водили по площадке, показывая основные локации предстоящего мероприятия.

С 18:00 стартовала BBQ-вечеринка с большим количеством развлечений, выступлениями сотрудников НАГ под акустическую гитару и группы "Отпетые мошенники". Вечер удался на славу, даже поздним вечером многие не хотели расходиться по номерам.

Утром следующего дня, в четверг, 23 мая, после завтрака, стартовала деловая часть мероприятия. Открыл деловую часть конференции генеральный директор компании НАГ, Дмитрий Самоделко.

До обеда работал только один большой зал, а после обеда, во время которого была сделана общая фотография участников, заработало сразу четыре потока докладов. 

В большом холле перед залами в течение всей конференции работал шоурум.

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

Следующий рабочий день конференции начался в 10:00 с докладов и мастер-классов сразу в четырех залах.

Вечером участников ждала развлекательная программа и спокойный вечер финального дня конференции.

Всего в работе конференции приняло участие свыше 900 человек из более чем 150 городов России. 

Лучшие 10 спикеров конференции по мнению участников КРОС:

• Семенцов Алексей.
• Колесникова Карина.
• Каримов Шавкат.
• Фёдоров Макс.
• Галушко Дмитрий.
• Петров Дмитрий.
• Шабаев Александр.
• Леонтьев Алексей.
• Петров Андрей.
• Рагуля Роман.

Материалы для скачивания

• Выборочно презентации докладов на КРОС-2024 можно скачать здесь. Все презентации одним архивом - здесь.
• Видеозаписи докладов из двух залов доступны по ссылке.
• Фотографии конференции КРОС-2024 можно скачивать по этой ссылке.

До встречи на КРОС-2025!

Почему был разработан «Агат»? Во-первых, потому что была потребность в подобном устройстве на рынке, на что указывали многочисленные клиенты «Стрим Лабс». Во-вторых, потому что была потребность в устройстве со специализированными характеристиками, которое мог бы полностью обслуживать отечественный производитель. В-третьих, потому что отечественные аналоги устройства такого типа и с подобным функционалом не существовали. 

Компания «Стрим Лабс» «с нуля» выполнила работы по созданию аппаратного (на базе ПЛИС) и программного обеспечения «Агата». Устройство реализовано таким образом, что на одном и том же «железе» можно выполнять различные задачи путем замены программного обеспечения. В настоящий момент реализованы задачи преобразования транспорта ASI-IP (асинхронный последовательный интерфейс (в перспективе также будет применяться SDI – последовательный цифровой интерфейс, поддерживающий скорости до 3 Гбит/сек), а также резервирования 2022-7, на очереди – задачи мультиплексирования сигналов и специализированной компрессии JPEG XS. Но, разумеется, этим возможности «Агата» не исчерпываются. 

Реализация JPEG XS будет осуществлена на российском рынке впервые. Это перспективный формат сжатия видеоизображений, который не приводит к потере качества и может использоваться для сжатия высококачественных видеосигналов для передачи через стандартные интерфейсы (такие как 10G). Помимо сжатия студийных видеосигналов JPEG XS может использоваться в системах космической связи, технического видео и других подобных. 

Актуальные сценарии применения «Агата» показаны на Рисунке 1. К концу 2024 года будут реализованы новые сценарии применения, показанные на – на Рисунке 2. В зависимости от решаемых задач сценарии могут комбинироваться. 

Рисунок 1. Актуальные сценарии применения 

Рисунок 2. Перспективные сценарии применения

Примечания: 

1. SMPTE ST 2110 – стандарт синхронизированной передачи компонентов телевизионных сигналов по IP-сетям.

2. SMPTE ST 2022– 6 – стандарт передачи некомпрессированных телевизионных сигналов по IP-сетям. 

Необходимость в преобразовании телевизионных сигналов возникает, в частности, при трансляции федеральных мультиплексов цифрового телевидения, официальных и спортивных мероприятий и востребована «магистральными» операторами, такими как «Синтерра Медиа». 

Александр Стрельцов, заместитель директора «Синтерры Медиа»: «Основное направление деятельности «Синтерры» – распространение телевизионных сигналов на территории РФ. «Агат» успешно прошел тестирование и в 2024 году планируется для установки более, чем на 100 объектах. Один «Агат» успешно выполняет преобразование и резервирование сигналов 128 телевизионных каналов с общим битрейтом около 8 Гбит\сек».

Задачи, которые предстояло решать компании «Стрим Лабс», не так просты. Телевизионные сигналы – сигналы реального времени. Они должны обрабатываться в момент поступления, их нельзя положить «на склад». При этом скорости этих сигналов довольно высоки. 

Одна из сложных задач, которые были решены – достижение задержки в обработке сигналов менее 5 миллисекунд. Обработка и преобразования видеосигналов для профессионального применения требуют, чтобы задержка обработки была минимальной. Для достижения минимальной задержки требуется тщательная работа по разработке «железа» и созданию программного обеспечения, способного оптимально работать с этим «железом». Эта задача не специфически телевизионная – вместо телевизионного сигнала может быть, например, сигнал телеметрии. 

Другая сложность – обеспечение «бесшовного резервирования» сигналов. Для бесшовного резервирования сигналов реального времени должна быть достигнута точность переключения «байт в байт». При этом должны обеспечиваться жесткие требования к сетевому джиттеру (проще говоря – его не должно быть). Как следует из слов Александра Стрельцова – задача бесшовного резервирования выполняется «Агатом» для 128 сигналов одновременно! 

Максим Искорнев: «В «Агате» мы реализовали технологию бесшовного резервирования по стандарту SMPTE ST 2022–7. Но технические решения, которые мы разработали, могут быть использованы при резервировании и других сигналов». 

Таким образом, обе упомянутые сложности не обязательно относятся к вещательному телевидению. Это универсальные проблемы работы с сигналами на высоких скоростях. Поэтому достижение в одной предметной области может привести к достижениям в других. Аналогичные по функциям решения могут разрабатываться для применения в системах технического зрения, в удаленном управлении промышленными объектами, техническими комплексами разного назначения, аэропортами. При необходимости устройство «Агат» может быть доработано для соответствия требованиям, применяемым в различных предметных областях. 

Как общетехнические, так и специфические сложности были успешно преодолены при создании шлюза «Агат». Компанией была разработана схемотехника, печатная плата, микропрограммное и прикладное программное обеспечение. Весь цикл работ выполнен исключительно специалистами компании. Кроме того, «Стрим Лабс» выполнил изготовление как опытных экземпляров, так и первой промышленной партии на собственной производственной базе. 

Пользователь управляет «Агатом» при помощи веб-интерфейса, т.е. удаленно. Для интеграции с внешними системами управления реализован REST API. Таким образом, устройство может быть применено как отдельно, так и в составе средств с централизованным управлением, сложных технических комплексах.  Специалисты могут обратиться в «Стрим Лабс», чтобы получить описание REST API, и компания будет поддерживать процесс интеграции.

С учетом легкой адаптируемости (путем замены программного обеспечения) «железа» к специфическим задачам и возможности централизованного управления «Агат» является «фундаментом» будущих систем преобразования сигналов. Но использовать «Агат» можно прямо сейчас, поскольку устройство может эксплуатироваться автономно (или с использованием REST API) – как делает «Синтерра Медиа». 

Настоящая перспективная разработка никогда не останавливается. В «Стрим Лабс» начата работа над следующим поколением «Агата». Основная цель – модульность и уменьшение размеров, поскольку для ряда приложений требуется высокая плотность устройств в одной локации. Планируется создание универсального шасси, в котором можно будет разместить несколько «Агатов» совместно с другими решениями «Стрим Лабс». 

Разумеется, успех достигнут не на пустом месте – компания «Стрим Лабс» известна своими аппаратными и программными разработками с 1991 года. Создание «Агата» демонстрирует нам, что при содействии (даже небольшом содействии) со стороны государства, знания и умения, которые накопил частный бизнес, приводят к успешным разработкам, востребованным на рынках.  

Нехватка кадров (цитаты)

Нету потенциальных кандидатур! Вообще нету. Нет желающих идти на сложную работу за не слишком великие деньги. Молодежь уезжает из города. На рынке нет по адекватной цене квалифицированных. 

Нужно доучивать. Значительно уменьшилось количество откликов на вакансию монтажника (hh). 

Размещаем вакансии на hh. Зарплата конкурентоспособная по городу. Не идёт народ.

Уже полгода ищем людей.

Мы не можем найти монтажника уже 4 месяца, за все время был отклик от 2 человек. Один не пришел, а второй - не подошел.

Людей вменяемых нет. Все тупые.

Если кратко: качество кадров сильно ухудшилось, то есть можно найти только спецов начального уровня и потом их приходится обучать, я имею ввиду если искать в зарплатной вилке для этих должностей. Ну, и квалификация соискателей. Кто-то вообще без понятия, что такое телеком и Интернет, в принципе

Либо никто не приходит , либо приходят те, кто совершенно для этой работы не походит. 

Сложности с наличием квалифицированного персонала готового пойти в найм, а также с сильно увеличившимися ожиданиями оплаты труда.

Сложность в повышении зарплатных ожиданий сотрудников в 1,5...2 раза.

Маленькое количество откликов/соискателей. Зарплатные запросы/ожидания существенно превышают текущие заработные платы утвержденные в соответствии со штатным расписанием в компании.

Никто не приходит, А кто приходит - не могут работать.

Зарплата на 100.000 - приходят либо толстожопые люди на 120 кило, которые думают что там только баранку нужно крутить, либо люди, которые не знают, что такое шуруповёрт и отвёртка.

Общий рост оплаты труда в стране и дефицит кадров приводит к росту ожиданий оплаты труда у сотрудников.

Сложности именно в поиске специалиста готового (со знаниями, умениями и навыками).

Если брать специалиста с перспективой, частые случаи нежелания обучаться, развиваться и отсутствие видения перспектив.

Вывод: в 2024 году провайдеры массово столкнулись с такой проблемой, как нехватка рабочих рук. 

Возникает вопрос - куда же ушли люди? Вот те, кто раньше трудился в провайдерах? Вот что на эту тему говорят сами провайдеры.
 

Куда уходят? (цитаты)
 

В целом, проблема сейчас в том, что люди не готовы работать руками. Те, кто готов был идти в монтаж, сейчас зарабатывают в иных местах: зона СВО, и, как не удивительно - курьеры. Курьером при свободном графике, но с активной позицией можно зарабатывать 90+.

Люди из глубинок уезжают на заработки,  в т.ч на СВО и в оборонку (сейчас там платят хорошо). На мой вопрос "почему?", отвечают примерно так: "зачем мне горбатиться за 60-80тыс и быть связистом, если за 120-150 я буду ящики колотить или патроны собирать?".

Есть такие, кто получив опыт, уходят в столицу, где уровни ЗП выше, чем в регионах. А соревноваться со столичными уровнями просто нереально.

СВО и очень много людей уезжают на работу вахтовым методом. Плюс к этому, мы находимся в демографической яме.

Ну если в двух словах, то люди нашли альтернативу в курьерах Яндекса и прочих. Таким образом, поиск сотрудников усложнился, мало откликов. Вторая причина это ... некому работать из-за демографической ямы.

Людей в республике, подходящих по возрасту и полу, стало меньше, кто не ушел воевать - уехал на заработки на новые территории.

Статус работы монтажником низок, люди работая в такси или баристой могут получать примерно равные деньги и не приходится лазить по столбам.

У нас  рынок труда весь пропылесошен Норильским никелем, Удоканской медью и СВО. Толковые уходят в первые две организации или уезжают, не особо толковые едут на заработки на СВО. 

Очень много народа ушло на СВО.

Сложность в том, что в телекоме  зарплаты низкие , люди предпочитают работать курьерами и таксистами. Допустим, одна из основных причин, там в удовольствие могут особо не работая руками, зарабатывать в два раза больше, 

Людей, которым еще помимо монтажа можно и нужно работать головой, допустим в видеонаблюдении, где нужно настраивать, предпочитают выбирать не провайдеров, а подрядчиков, так как там сдельная оплата. 

Перебивают заводы, которые работают на оборонку. Невозможно перебить их условия по зарплате и прочим плюшкам.

Сложность выражается с отсутствием кандидатов на вакансии монтажников. Я полгода назад ушел из Ростелекома (Сочи). Одна из причин ухода - это массовый уход монтажников (специалистов) либо к альтернативным операторам на лучшие условия, либо просто уход из отрасли в банальные доставки. Также, это относится и к молодым начинающим специалистам, которые вообще не рассматривают свою жизнь/работу монтажником в Операторе.

Молодые специалисты  без опыта с завышенными потребностями, т.к. "я курьеров в яндексе, самокате, мегамаркете и т.д." заработаю больше чем вы предлагаете.

Присоединение новых территорий к РФ отразилось очень в т.ч. на Ростовской области, т.к. грамотные технические спецы и подрядчики рванули туда за "золотом". Там цены на некоторые виды работа в 10 раз выше, чем платят операторы связи в нашем регионе.

Вывод - есть отток кадров из отрасли связи в зону СВО, на оборонные предприятия, в сферу обслуживания (такси, курьерство, баристами). Плюс, демографическая яма. Нужные нам сотрудники просто не родились в 90-е.

Итак, провайдеры столкнулись с тяжелым кадровым кризисом. Вопрос : как это отразилось на бизнес-процессах в провайдерах?
 

Проблемы с бизнес-процессами (цитаты)
 

Если кто-то увольняется, то начинаются переработки или срывы подключений.

В декабре-январе у нас в очереди на подключение было более 100 абонентов. Они ждали подключения почти месяц!

На процессах рабочих пока не отразилось, но новые задачи и процессы без расширения штата внедрить нет возможности.

Вопрос поиска кадров сейчас стал отнимать очень много времени сил и финансов.

Приходится терпеть нынешнее, не всегда адекватное отношение к работе от своих сотрудников и платить выше рынка.

Периодически, подрядчиков берем недешевых.

У тех сотрудников, кто остался, больше работы стало. Переработки.

Новые сотрудники, кто приходят, качественно работать не хотят, приходится постоянно держать на контроле.

В прошлом году начали на постоянной основе работать с подрядчиками, что выходит дороже, если бы объектами занимались собственные бригады.

Катастрофически не хватает даже монтажников! Бизнес на паузе. :(

Очередь на монтаж камер растёт, внутренняя конкуренция за монтажников.

Закрываем глаза на переработки. Есть персонал готовый работать больше.

Периодически есть торможение в сроках монтажа из-за нехватки сотрудников.

На бизнес-процессах кадровый голод отражается таким образом, что не хватает рук для эксплуатации и развития сети, развитие приходится замедлять, какие-то направления реализовывать силами подрядчиков, инвестируя большие деньги нежели закладывались изначально, что в свою очередь тоже приводит к замедлению развития.

Работать некому. Радикально выросла очередь на подключения и сроки устранения аварий.

Зашиваемся с выполнением монтажных работ.

На бизнес-процессах отражается так,  что приходиться аутсорс больше нанимать, соответственно дороже...

Увеличились сроки выполнения задач, качество сильно снизилось так как приходится брать молодых неопытных и обучать их на объектах , доходит до того что у меня инженера офисные выезжают и переделывают работу.

Из-за дефицита кадров мы замедлились в развитии, вынуждены несрочные, но важные дела отодвигать потому, что весь ресурс съедает текучка. 

Ну и переработка соответственно. Те, кто есть, работают с дополнительными сменами. Кто-то держится, кто-то не выдерживает и уходит

В случае увольнения кого-то из сотрудников монтажного отдела, мы столкнемся с дефицитом рабочих рук. Кадрового резерва уже нет.

Резюмируем. Где-то запас прочности ещё есть, и ситуацию удерживают старые сотрудники. Там, где запас прочности кончился, там начинаются проблемы — или приходится обращаться к дорогим подрядчикам, или просто доходит дело до паралича процессов — невозможности подключать клиентов и, что самое страшное, увеличение сроков устранения аварий. Видимо, кадровый кризис накатывает неравномерно. Где-то ситуация получше, где-то похуже, но в целом напряжение растёт везде. Где-то прорывает, и очевидно, что если ничего не предпринимать, то дальше будет только хуже.

Отрасль связи столкнулась с острейшим кадровым кризисом. Вот как формулируют ключевую проблему сами провайдеры.

Формулировка проблемы (цитаты)

В целом проблема ясна как день. Нежелание работодателя платить больше и нежелание кандидатов идти на предлагаемую зп

Конкуренты зарплатой обученных кадров вымывают. Поднять ЗП нет возможности из-за демпинга со стороны новых крупных операторов, взять студента, научить — убегает.

Пробовали набирать студентов и обучать. Результат околонулевой.

Сложность в том, чтобы платить монтажникам плюс 100% к зп на которой работали старые. ЗП у нас в два раза отстала от рынка. По некоторым позициям в три раза.

С крупными корпорациями, оборонными заводами конкурировать по размеру ЗП бесполезно

Есть вроде грамотные монтажники. Но они больше хотят денег, поэтому сидят на подряда от Ростелекома и от крупных федералов. На оклад не соглашаются ни в какую.

Выражается это в первую очередь в росте зарплат. Ещё год назад 80 т. р. на спокойной работе и 100 т. р. с подвигами было нормальной расценкой — при которой народ не бежал и мы могли закрывать вакансии. Прошлым летом у нас стал уходить — на суммы в полтора раза больше. Пришлось поднимать ЗП.

Вывод: отрасли связи, в дополнение ко всем остальным неприятностям в виде СОРМа, Яровой, поборам от балансодержателей, росту цен на оборудование, добавилась необходимость радикально наращивать ФОТ. Выдержат ли это бюджеты? Провайдер, к сожалению, деньги не печатает, а выручка у провайдеров такими темпами не растет.

И как же провайдеры выкручиваются? Вот что нам ответили респонденты.

Как выкручиваемся? (цитаты)

Мы получили 0 откликов на Авито и НН, но нашли "по знакомству" практически всех.

Приходится работать с техникумами.

Чтобы на процессах сильно не отразилось, пришлось поднять зарплату.

Работаем усиленными темпами, отправляем сотрудников в командировку в те филиалы, где людей нет.

Сейчас в процессе проработки затаскивание студентов техникумов из регионов.

Бизнес-процессы усложнились и нам приходится заниматься микроменеджментом каждой бригады, чтобы вырвать из них максимум ресурса.

Убрали из плана допродажи услуг и оборудования. Оставили сервис и подключения.

Сильно страдают от этого большие операторы, которые рассматривают ФОТ монтажников в разрезе страны и не готовы быстро отреагировать на рынок. Теперь я работаю в операторе городского масштаба, где мы мониторим рынок города и стараемся завлекать специалистов рублем. Но, учитывая отсутствие в принципе специалистов на рынке, идёт тяжеловато.

Выходим из ситуации след. образом: работаем с техникумом связи, привлекаем студентов на практику уже с 3 курса. через воронку из 20 практикантов, на работу устраиваются 2.

Текущий персонал переводим из  строителей в эксплуатацию, отдавая стройку на  аутсорс.

Пришлось менять процессы в сторону снижения требований/упрощения задач. А тем, кто соображает - подняли зарплату и добавили задач.

Максимально делаем упор на телефонную тех. поддержку, снижая нагрузку на выездной персонал.

Обучили менеджеров прямых продаж нехитрым подключениям. Они помогают снять часть заявок.

Выводы

Итак, волшебной пилюли никто не изобрел, все крутятся как могут - по возможности, повышают зарплаты у себя, ищут новые каналы привлечения сотрудников, оптимизируют существующие ресурсы, часть работ отдают на подряды, учатся работать со студентами. То есть, ситуация сложная, но не безнадежная

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

Приглашаем всех на онлайн-конференцию 18 апреля. Будем обсуждать кадровый кризис и пути выхода.
 

АМОР, хотя и объединяет свыше 100 операторов связи со всех федеральных округов России, пока ещё совсем "грудное дитя" – ведь создана она 15.08.23.

Задачи ассоциации: помочь малым операторам связи сохранить бизнес во времена резкого "закручивания гаек" и наметившейся стратегии государства на сокращение количества операторов связи.

Давно понятно, что новых детей телекома не будет рождаться, но наметилась тенденция и на сокращение малых операторов. Если большинство микроОператоров связи работают нелегально и они, по сути, неинтересны Налоговой (выручка в зависимости от региона конечно разнится, но с мелкими много формальных процедур надо пройти, и часто там штрафов можно и не получить в бюджет из-за неплатежеспособности организации), то мелкие Операторы ищут кому продаться. Однако и у крупных Операторов связи тоже всё не гладко: например, СОРМ не реализован до конца (а именно: Система хранения Данных ( содержимого сообщений) по ФЗ «Яровой»).

В текущей атмосфере АМОР помогли нашим членам:

• отбиться от запросов ФСТЭК по критической информационной инфраструктуре (КИИ),
• подготовили пакет документов по воинскому учёту;
• проконсультировали по Системе АнтиФрод, в т.ч. помогли отбиться от штрафов за неподключение,
• простроили алгоритмы по входу в жилые многоквартирные дома;
• получили около 10 решений различных органов и управлений ФАС России о необходимости снижения цены за доступ к опорам для размещения кабелей связи;
• получили свыше 15 ответов от регуляторов, в т.ч. ФСБ России, Минцифры, Роскомнадзора, т.ч. по: СОРМ, КИИ, Антифроду, блокировке запрещенной информации, ТСПУ, недискриминационному доступу к инфраструктуре;
• делаем Правовую экспертизу проблемных проектов Телеком НПА для Федерального портала проектов нормативных правовых актов;
• ведем работу с поставщиками СОРМ;
• ассоциацию включили в рабочую группу по подготовке Цифрового кодекса России.

16 января Верховный суд рассмотрит заявление членов Ассоциации об оспаривании норм п.39 правил недискриминационного доступа к инфраструктуре для размещения сетей электросвязи (№ 2106 от 22.11.2022) в части отмены нормы о возможности взимания с Операторов связи платы за перенос ВОЛС при реконструкции/модернизации/ремонте опор, коллекторов, возникший по инициативе владельца инфраструктуры.

15 февраля планируем провести конференцию по регуляторике. Разослали приглашения всем регуляторам, часть уже откликнулись.

Что ждет телеком

1. СОРМ: великий и ужасный
 

С 01.01.2024: Один миллион рублей:

• Штрафа за нереализацию СОРМ (ФЗ от 13.06.2023 N 223-ФЗ). Протокол составит куратор ФСБ. Дело рассматривает Мировой суд.
• Госпошлины за 1 новую лицензию (ФЗ от 28.09.23 № 497-ФЗ), включая лицензию на Интернет (телематика), передачу данных ( с голосом и без), все виды телефонной связи (кроме таксофонов и СКД), каналы связи.

С 01.09.2024 из-за нереализации СОРМ добавляются следующие моменты:

• Роскомнадзор имеет право приостановить лицензию на 3 мес. (п. 3 ст.37 ФЗ О связи в ред. ФЗ 04.08.23 N 473-ФЗ).
• Непродление лицензии при отсутствии действующих акта /плана СОРМ (проект).
• Не изменение территории действия, невключение использования радиоЧастот (проект).
• Отказ в новой лицензии из-за несогласования ФСБ схемы (проект).

2. Построение Суверенного Интернета

Теперь новые Операторы, желающие начать оказывать услуги Интернет (лицензия на телематику), обязаны уведомить ГРЧЦ о начале оказания услуг (ППРФ № 2126 от 11.12.2023).

Вдобавок, с 01.09.2024:

• Отказ в новой лицензии на Интернет из-за несогласования РКН схемы пропуска трафика через ТСПУ ( ч.7 ст.30 ФЗ «О связи»).
• За непропуск трафика через ТСПУ – прекращение лицензии ( п.7 ч.1 ст. 39 ФЗ О связи).

По сути, путём построения российского аналога «Золотого Щита» продолжается отделение российского сегмента Интернет. Для этого ГРЧЦ в т.ч. консультируется с китайскими товарищами

3. Проверки Роскомнадзора

Плановые: отменены до 2030 г. ( ППРФ № 372 от 10.03.2023).

Внеплановые: ограничены причинением вреда жизни, здоровью и безопасности и проводятся только по согласованию Прокуратуры (ППРФ от 10.03.22 N 336 в ред. ПП РФ от 14.12.23 № 2140).
 

4. АнтиФрод (Телефония)

Местным телефонным операторам дали понять, что если до февраля 2024 года они не подключатся к гос. системе, будут большие штрафы (от 300 т.р на юрлицо, см.: ч.3 ст.13.2.1. КоАП РФ).
Также, хотят сократить количество лицензий, объединив передачу данных с голосом и без, в единую лицензии на передачу данных.
К 01.09.2025 хотят дать возможность пропускать голосовой трафик из Сети передачи данных в ТФОП только лицам, имеющим лицензию на Местную Телефонию и ПД.

5. Вход в жилые многоквартирные дома (МКД)

Пока законопроект Хинштейна принят только в 1 чтении, для легального размещения сетей нужно 2/3 собственности.
В текущей ситуации, когда Управляющие компании повышают плату за пользование, проходит много судебных процессов. По сути, если цена завышена, надо самостоятельную оценку или суд. экспертизу. Так можно добиться снижения стоимости. 
Потому как, по абз. 2 чт.3 ст.6 ФЗ «О связи» собственники вправе требовать соразмерную плату за пользование имуществом МКД.

Неизбежные итоги

• Слияние / поглощение будет в ТОПах. 
• Участятся случаи ухода в потребительские интернет-кооперативы или деятельности без лицензии.

Но "вода всегда дырочку найдёт".

Дмитрий Михайлович Галушко к.ю.н.,
Президент Ассоциации Малых Операторов связи Регионов (АМОР)
Генеральный директор ordercom.ru

 

Да, работаем без лицензий. В свое время думали об узаконивании деятельности, но все время были заняты работой. Пришел как-то крупный провайдер и сильно «пощипал» абонентов. Денег стало меньше, пока получишь все бумажки, последнее придется отдать. Так и работаем.

Роскомнадзор не пристает?

Нет, не пристает. У нас много компаний, которые так работают в городе.

А кто из федеральных зашел? Ростелеком, Дом.ру?

Ну Дом.ру начал в частный сектор заходить, Ростелеком зашёл в частный сектор, и еще одна местная компания! У них подрядчики ценники рубят, поэтому получается дорого для абонентов. Сейчас мы занимаемся модернизацией сети и подумываем подтянуть стоимость тарифов к конкурентам.

Почему лучше подключиться к вам, а не к Дом.ру?

Мы стараемся строить сети там, где нет федеральных компаний, а только такие, как мы. Плюс, у больших компаний задача, в большей степени, денег срубить, чем дать людям дешевле тариф. Тарифы для частного сектора сильно завышены у крупных провайдеров! Считаю, что у многих из них техническая поддержка работает не ахти!

С абонентами договора заключаете? Или просто подключаете и объясняете как пользоваться?

Раньше заключали на обслуживание и всё. А сейчас - просто так подключаем, без ничего. Объясняем, что сейчас все в электронном виде, и что "всю исчерпывающую информацию вы можете получить в личном кабинете".

С точки зрения бизнеса, как у вас все выглядит? Должна же быть какая-то организационно-правовая форма для приема денег, помещение, наконец, серверная. Вы не боитесь, что к вам завтра придут?

Как я уже сказал, сейчас все электронном виде. Это как получить кредит в банке - достаточно нажать одну кнопку. Сейчас офис – это ваш телефон. Поэтому у нас нет даже фирмы, нет помещений, все через интернет. Прием платежей за интернет мы осуществляем любым удобным способом для абонента, в том числе, и через систему быстрых платежей. После поступления платежа, деньги автоматически зачисляются на баланс и списывается оплата за услуги связи. В зависимости от района, минисерверные ставим прям на чердаках, бывает - на столбах. Все они подключаются к биллингу в облаке.

Какая платежная система решится на сотрудничество по такой "серой" схеме? Вы выступаете как физическое лицо?

Таких понятий нет, мы выступаем как партнер. Есть куча платежных систем, я не буду их называть. В основном, они предназначены для высокорискованных видов деятельности, например, онлайн-казино. По факту, мы не предоставляем данных о себе, кроме описания услуг. При совершении платежа, деньги уходят в никуда, их уже не отследить. Вывести я их могу в любую точку мира.

То есть смысл вашего "серого" Телекома в том, что его не существует на бумаге? Деньги вам не платятся, а оборудование установлено неизвестно где?

В любой непонятной ситуации говорим, что это не мы! Для примера, если ловят за столбы, говорим, что нам сказали вешать сюда, прикидываемся любой несуществующей организацией, вроде как работающей на конкурентов.

Получается, вы не платите за столбы? Как с каналом вопрос решаете?

Смысл за них платить?! Паутины висит столько, что не с первого раза свой кабель находим! 

С каналами по-разному, в каждом районе своя история. В некоторых поселках оформляем левую учетку у конкурента на местного жителя. Иногда приходится брать канал «официально». 

Перспективы роста есть?

Да. Мы и начинали построение сетей с ценами ниже, чем у того же Ростелекома! И много людей подключили и еще подключим!

Сейчас многие операторы пугаются что получение лицензии будет стоить 1 млн. руб. по новым законам. Огромные штрафы за СОРМ. Что можете по этому поводу сказать?

Лицензия нужна, чтобы кормить людей "сверху", и чтобы все повышали цены и сдирали больше денег с обычных людей. Мне кажется, если отменить все налоги и всякую такую канитель, то и цены будут намного ниже!

Спасибо за ваши ответы и что уделили мне и нашим уважаемым читателям время. Для меня это небольшой шок, что в конце 2023 года существуют пионеры на рынке телекома, и до сегодняшнего дня так всё ещё возможно работать. Никому не советую использовать ваш опыт, это является грубым нарушением закона, которое повлечет к ответственности.

Не за что! Звоните, пишите! :)

……….

Вот такая жизненная ситуация в нашей отрасли. Согласитесь, довольно интересная. Анализируя происходящее, мы видим, что ребята покрупнее начинают регистрировать «кооперативы», кто-то взял лицензий с запасом. 

Точка невозврата 1 января 2024 года, когда начнет действовать административная ответственность за отказ от системы оперативно-розыскных мероприятий (СОРМ) и госпошлина за лицензию 1 миллион. И вот какие мысли: не получится ли так, что мелких операторов начнут штрафовать при первой возможности. И наличие лицензий на миллионы превратится не в ценность, а в потенциальный штраф. 

Для многих компаний один миллион равносилен закрытию.

• Введение.
• STP (802.1D, Spanning Tree Protocol).
  • Выбор корневого коммутатора (Root Bridge).
  • Определение корневых портов (Root Port).
  • Определение назначенных портов (Designated Port).
  • Таймеры STP и изменение топологии.
  • STP Toolkit.
• RSTP (802.1w, Rapid Spanning Tree Protocol).
  • RSTP vs STP. Изменения в BPDU, новые роли и состояния портов.
  • Новые типы линков.
  • Proposal & Agreement.
• MSTP (802.1s, Multiple Spanning Tree Protocol).
  • Взаимодействие внутри региона MSTP.
  • Взаимодействие между регионами MSTP.
  • Формат MSTP BPDU.
  • Роли портов в MSTP.
  • Topology change.
  • Взаимодействие MSTP с проприетарными PVST+/RPVST+.
• Настройка и работа STP на коммутаторах SNR.
  • Настройка spanning-tree на основных сериях коммутаторов SNR.
  • Взаимодействие SNR с проприетарными PVST+/RPVST+.
  • Настройка spanning-tree на серии S5210.
• Заключение.

Введение

В любой современной компьютерной сети, будь то сеть крупного интернет-провайдера или корпоративная сеть небольшого предприятия, необходимо так или иначе обеспечить резервирование каналов связи для бесперебойной работы сети или для минимального простоя сервисов, ведь в современных реалиях, даже минутное отсутствие доступа к сети может быть очень критичным как для клиентов, так и для оператора. Под резервированием, например, понимают организацию дополнительных линков (дополнительного плеча), чтобы в случае падения линка, трафик перетек на второе плечо – тогда пользователи и не заметят простоя связи.

Помимо резервирования, также необходимо обезопасить свою сеть, в частности, от возникновения нежелательных колец/петель. Например, если кто-то случайно, а, может быть даже, специально захотел организовать дополнительный линк между коммутаторами (возможно, этот человек как раз хотел добиться некоего резервирования, либо просто хотел навредить нам) и таким образом организовал кольцо. Или даже уже был организован резервный линк, чтобы его можно было поднять в случае аварии, но кто-то по ошибке включил административно порт на коммутаторе при другом активном линке.

Все эти задачи по устранению нежелательных колец и петель коммутации в совокупности с отказоустойчивостью решает небезызвестный протокол STP (Spanning Tree Protocol). Именно о нем и его видах и пойдет речь в данной статье.

Несмотря на то, что в сети Интернет уже множество раз рассматривали работу данного протокола, мы сделаем это еще раз и постараемся сделать максимально подробно, так как, во-первых, с момента основания протокола прошло достаточно большое количество времени, вышло очень много статей, вебинаров, обзоров, где каждый по-своему рассматривал данный протокол, мы же постараемся освежить все и привести к одному виду, а во-вторых, не помешает освежить знания перед тем, как мы будем рассматривать принцип работы STP/RSTP/MSTP и их настройку и работу на коммутаторах SNR.

Но зачем вообще нам нужен STP, почему мы просто так не можем организовать дополнительный физический линк? Чем вообще может быть чревато наличие колец в сети?

Чтобы ответить на этот вопрос, вспомним принцип работы коммутатора. Коммутатор оперирует такими сущностями, как кадры (frame). Это PDU канального уровня. И при своей работе коммутатор опирается на адреса в этих PDU, которые называются MAC-адреса - адреса канального (L2) уровня.

Рис. 1. Пример самого распространенного формата Ethernet кадра из Википедии

Когда на порт коммутатора приходит кадр, коммутатор смотрит в поле Ethernet-заголовка SMAC (Source MAC Address - адрес отправителя или адрес источника), извлекает оттуда MAC-адрес и записывает в свою таблицу коммутации (таблицу MAC-адресов или CAM-таблицу). 

Выглядит эта таблица следующим образом: соответствие VLAN, в котором был изучен MAC-адрес, к самому MAC-адресу и к порту, за которым был изучен данный MAC-адрес (т.е. с какого интерфейса к нам пришел кадр с данным MAC-адресом отправителя). Могут встречаться еще различные поля в таблице MAC-адресов, но сейчас они нам не так интересны, мы вспомнили только самые важные для изучения STP.

Рис. 2. Кадр пришел на один из портов коммутатора

Рис. 3. Пример записи из таблицы MAC-адресов

Далее коммутатору необходимо перенаправить данный кадр. Для этого он смотрит в Ethernet-заголовке поле DMAC (Destination Address - адрес получателя или адрес назначения), и затем коммутатор запускает процесс поиска MAC-адреса получателя в своей таблице коммутации. 

Когда коммутатор находит запись в своей таблице о MAC-адресе получателя, то без лишних раздумий коммутатор отправляет кадр на порт, соответствующий данному MAC-адресу.

Однако, если записи в таблице о данном адресе нет, то коммутатор отправит кадр на все порты, кроме того порта, откуда пришел данный кадр (такой тип трафика называется "unknown-unicast").

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

Помимо этого, некоторые кадры заведомо могут быть широковещательными (broadcast, т.е. иметь MAC-адрес назначения FF-FF-FF-FF-FF-FF), например, при работе таких протоколов как ARP, DHCP, и т.д., т.е. когда мы не знаем, кому именно отправлять пакет, мы его отправим всем, в надежде, что наша цель, кто бы то ни был, получит данный кадр и ответит нам (при необходимости). Ну и раз уж мы вспомнили broadcast-трафик, вспомним и многоадресный или мультикаст (multicast) трафик, когда трафик точно также разливается во все порты, кроме того, откуда он пришел.

Итого, у нас есть три метода отправки трафика, при котором трафик в любом случае будет отправляться во все порты, т.к. мы не знаем, куда именно или кому его отправлять. Такой трафик называется BUM-трафик (Broadcast, Unknown-unicast, Multicast).

Рис. 4. Пример отправки unknown-unicast трафика

Если мы вновь обратимся к Ethernet-заголовку (неважно какой формат: Ethernet II или IEEE 802.3), в нем мы не увидим поля, которое ограничивает время жизни кадра (как, например, поле "TTL" в заголовке IPv4-пакета, или "Hop Limit" в фиксированном заголовке IPv6, т.е. на уровне L3). А это значит, что пакет будет блуждать по сети вечно, точнее до тех пор, пока кольцо не будет разорвано (имеется в виду физическое/административное отключение линка, либо выключение коммутатора).

Особо в этом ничего страшного нет, что у нас по сети будет вечно блуждать пара пакетов. Однако со временем один отправленный ранее пакет, бесконечно блуждающий в нашем широковещательном домене, размножится, плюс не стоит забывать, что большинство других современных протоколов используют широковещательные сообщения для своей работы (тот самый BUM-трафик). И если в обычной ситуации кол-во широковещательных пакетов не должно составлять более 10% от общего трафика в сети, то в данном случае их кол-во будет очень быстро расти, вследствие чего уже через несколько минут сеть окажется неработоспособной: потери трафика до 90-100%, отсутствие возможности управления сетевыми устройствами и т.д.

Описанная ситуация при неконтролируемом росте BUM-трафика в сети называется широковещательный шторм, который является следствием возникновения колец и петель в сети.

На рисунке ниже показан пример начала широковещательного шторма. То есть, коммутатор увидел, что кадр содержит dst.mac (MAC-адрес получателя), запись о котором отсутствует в его таблице, поэтому он отправит кадр во все порты. То же самое сделают и другие коммутаторы (также кадры будут отправляться и в порты, за которыми находятся конечные устройства, там они будут отбрасываться, ведь кадр предназначается не им). Причем будет уже две копии кадра, которых со временем будет становиться еще больше, ведь у нас все четыре коммутатора соединены между собой избыточными линками, а механизма TTL в Ethernet нет.

Рис. 5. Пример начала широковещательного шторма

Даже если сеть будет работоспособна какое-то время, мы можем столкнуться с еще одним неприятным явлением - MAC Address Flapping (флаппинг MAC-адресов). Суть данного понятия в том, что кадр, который отправил какой-либо пользователь, будет бесконечно ходить по сети, и коммутаторы будут изучать его и записывать MAC-адрес отправителя (Source MAC Address) в свои таблицы. Однако через некоторое время, точно такой же кадр будет получен уже на другом порту коммутатора, соответственно коммутатор изменит запись в своей таблице, полагая, что данный отправитель находится именно за данным портом (куда пришел кадр), хотя это может быть и не так. И так будет продолжаться постоянно: один и тот же MAC-адрес будет фиксироваться на разных портах, это и называется - флаппинг MAC-адресов. В результате этого явления, данные, предназначенные какому-либо получателю, вполне могут и не дойти до него, так как кадр будет отправлен в “неправильный” порт.

Избежать широковещательного шторма и флаппинга MAC-адресов нам поможет протокол STP.

STP (Spanning Tree Protocol) — сетевой протокол (или семейство сетевых протоколов) предназначенный для автоматического удаления циклов (петель коммутации) из топологии сети на канальном уровне в Ethernet-сетях. Первоначальный протокол STP описан в стандарте 802.1D. Позже появилось несколько новых протоколов (RSTP, MSTP, PVST, PVST+, ...), отличающихся некоторыми особенностями в алгоритме работы, в скорости, в отношении к VLAN'ам и ряде других вопросов, но в целом решающих ту же задачу похожими способами. Все их принято обобщенно называть STP-протоколами.

STP использует алгоритм STA (Spanning Tree Algorithm), результатом работы которого является граф в виде дерева (связный и без простых циклов).

Обратимся к определению из википедии: "Граф — математическая абстракция реальной системы любой природы, объекты которой обладают парными связями. Граф как математический объект есть совокупность двух множеств — множества самих объектов, называемого множеством вершин, и множества их парных связей, называемого множеством рёбер. Элемент множества рёбер есть пара элементов множества вершин." 

Если переводить дословно: spanning tree - охватывающее, связующее или остовное дерево.

Связующее или остовное дерево (как его чаще называют в математике) - это подграф без циклов, содержащий все вершины исходного графа. Грубо говоря, остовное дерево получается из исходного графа удалением максимального числа рёбер, входящих в циклы, но без нарушения связности графа.

То есть, возвращаясь от математики к сетям, связующее дерево содержит все исходные коммутаторы, но при этом в нем нет циклов, то есть избыточных соединений между этими коммутаторами. Это если рассматривать логическую топологию. Из физической топологии избыточные линки никуда не исчезают. Поэтому можно сказать, что физическая топология - полноценный граф, а логическая топология, полученная в результате работы алгоритма STP - подграф, где каждые две ноды соединены только одним путем.

Поэтому, как и было сказано ранее, основная цель STP, вне зависимости от реализации протокола - автоматическое удаление циклов (петель коммутации) из топологии сети на канальном уровне.

Сперва мы рассмотрим подробно три вида (реализации) STP:

• классический STP;
• RSTP (Rapid STP);
• MSTP (Multiple STP).

Также, вскользь упомянем про семейство проприетарных Cisco протоколов PVST и их взаимодействие с мультивендорными STP-протоколами. А затем рассмотрим их настройку и работу на коммутаторах SNR.

Если кто-то уже в деталях знает и понимает работу всех протоколов семейства spanning-tree, можно перейти сразу к рассмотрению главы: "Настройка и работа STP на коммутаторах SNR".  
 

STP (802.1D, Spanning Tree Protocol)

Первоначальный (классический) STP был разработан в 1985 году Радией Перлман (Radia Joy Perlman - американский программист и сетевой инженер), за что она в свою очередь получила прозвище «Мать Интернета», так как протокол STP сделал возможным появление массовых сетей с использованием технологии Ethernet, потому что иначе использование кольцевых топологий в Ethernet было бы невозможным.

Впервые STP был стандартизован IEEE (Institute of Electrical and Electronics Engineers) в 1990 году в стандарте IEEE 802.1D-1990, который в свою очередь был заменен на 802.1D-1998 в 1998 году. Данный стандарт описывает не только сам STP, в нем описано как в принципе нужно коммутировать трафик в Ethernet-сетях, и, соответственно, также описан протокол STP.

В 2001 году вышло дополнение к стандарту 802.1D - IEEE 802.1t-2001, где была изменена длина полей для создания уникального Bridge ID для каждого VLAN, и изменены значения path cost на линках, но об этом позднее.

В 2004 году как 802.1D-1998, так и 802.1t-2001, и опубликованный в том же 2001 IEEE 802.1w-2001 (стандарт для RSTP) были перенесены в IEEE 802.1D-2004 (причем оригинальный STP был удален из этого документа и был заменен на RSTP). Но об этом опять же позднее.

Далее углубляться в стандарты не будем, необходимо было поверхностно рассмотреть хронологию и принадлежность к стандартам, так как у тех, кто впервые разбирается с STP, может возникнуть небольшая путаница с этим. Сейчас нам важно то, что оригинальный STP принято ассоциировать со стандартом 802.1D, в котором он и был изначально описан.

Протокол STP работает на канальном (L2) уровне. STP позволяет делать топологию избыточной на физическом уровне, но при этом логически блокировать петли. Достигается это с помощью того, что коммутаторы в STP отправляют специальные сообщения BPDU и обнаруживают фактическую топологию сети. А затем, после определения ролей коммутаторов и портов, часть портов блокируется так, чтобы в итоге получилась логическая топология без петель.

Как мы уже сказали, в STP для общения и обмена информацией между собой коммутаторы используют специальные пакеты, так называемые BPDU (Bridge Protocol Data Units).

Сразу отметим из определения "Bridge" (сетевой мост). Если коротко, bridge - устройство, которое находится на промежуточной стадии между концентратором (он же хаб) и коммутатором. Протокол STP разрабатывался еще во времена, когда использовались сетевые мосты. Сейчас такие устройства в современных сетях, разумеется, не используются, как и хабы, поэтому под "bridge" мы в дальнейшем контексте будем понимать именно коммутатор.

Что же касается BPDU, то данные сообщения могут использоваться не только для протокола STP. Существуют еще, например, LLDP BPDU, LACP BPDU и т.д. Мы же в дальнейшем под BPDU будем понимать именно spanning-tree BPDU.

BPDU в STP бывают двух видов: конфигурационные (Configuration BPDU, также в литературе можно часто встретить определение “Hello BPDU”) и об изменении топологии - TCN (Topology Change Notification BPDU).

В классическом STP Configuration BPDU рассылаются именно корневым коммутатором (и ретранслируются остальными) и используются для построения топологии, вторые, как понятно из названия, отсылаются в случае изменения топологии сети.

Configuration BPDU имеет следующие поля:

• Protocol Identifier (Идентификатор протокола STP, 2 байта): 0x0000;
• Protocol Version Identifier (Версия протокола STP, 1 байт): 0 для STP;
• BPDU Type (Тип BPDU, 1 байт): 0х00 для Configuration BPDU;
• BPDU flags (Флаги, 1 байт): бит 0 (младший) для TC (Topology change), бит 7 (старший) для TCA (Topology Change Acknowledgement), остальные не используются;
• Root Identifier (Идентификатор корневого коммутатора, 8 байт): Root Bridge Priority + Root Bridge System ID;
• Root Path Cost  (Расстояние до корневого коммутатора, 4 байта);
• Bridge Identifier (Идентификатор коммутатора, 8 байт): Bridge Priority + Bridge System ID;
• Port identifier (Идентификатор порта, 2 байта);
• Message Age (Время жизни сообщения, 2 байта);
• Max Age (Таймер - максимальное время жизни сообщения, 2 байта);
• Hello Time (Таймер - интервал отправки Hello BPDU, 2 байта);
• Forward Delay (Таймер - задержка смены состояний, 2 байта).
   

Рис. 6. Пример дампа Configuration BPDU

    TCN BPDU состоит только из заголовка и имеет следующие поля:

• Protocol Identifier (Идентификатор протокола STP, 2 байта): 0x0000.
• Protocol Version Identifier (Версия протокола STP, 1 байт): 0 для STP.
• BPDU Type (Тип BPDU, 1 байт): 0x80 для TCN BPDU.
  
   

Рис. 7. Пример дампа TCN BPDU

Как мы можем заметить, BPDU сообщения STP инкапсулируются сперва в LLC (Logical Link Control - 802.2). Как мы помним, это верхний подуровень канального уровня модели OSI. LLC осуществляет управление передачей данных, а также обеспечивает проверку и правильность передачи информации по соединению.

Зачем это было сделано - непонятно, но факт остается фактом, STP инкапсулируется в LLC, даже если формат L2-кадра Ethernet - Ethernet II, а не 802.3 (по крайней мере так нам об этом сообщает Wireshark).

Сами BPDU, как правило, делятся на три условные части: это некий заголовок BPDU, Priority Vector и таймеры STP.

Заголовок BPDU занимает 5 байт и содержит такие поля как Protocol Identifier, Protocol Version Identifier, BPDU Type и BPDU Flags.

Priority vector занимает 22 байта и состоит из Root Identifier, Root Path Cost, Bridge Identifier, Port Identifier (передающей стороны), и еще при получении могут добавляться 2 байта Port Identifier (принимающей стороны), но в современных сетях этот параметр не используется, так как предназначен для разрешения неоднозначности в случае применения хабов и, соответственно, при полудуплексном режиме работы на каком-либо коммутирующем интерфейсе.

Подробно Priority Vector мы рассматривать не будем, скажем лишь, что вектор приоритета - это совокупность некой информации, которой обмениваются коммутаторы для определения активных маршрутов и вычисления топологии. Priority vector позволяет определять, какая BPDU лучше (superior), а какая хуже (inferior). Определяется это по 22 байтам содержимого.

Мы для простоты, как и все остальные, будем сравнивать BPDU не по значению вектора приоритета, а по отдельным полям, которые входят в него: Root Identifier, Root Path Cost, Bridge Identifier, Port Identifier. Как это происходит, мы узнаем немного позднее.

И последняя часть BPDU - таймеры, занимают 8 байт, используются непосредственно при работе STP, при сходимости сети и т.д.

Все коммутаторы (по умолчанию каждые 2 секунды) отправляют BPDU со всех работающих портов на мультикастовый Ethernet-адрес 01-80-C2-00-00-00 (в случае обычного мультивендорного STP) или, например, на 01-00-0C-CC-CC-CD (в случае проприетарного Cisco PVST), который прослушивают все коммутаторы, на которых включен и запущен STP. Если на коммутатор приходит Hello BPDU, то он понимает, что за этим портом также находится коммутатор, а не какое-то конечное устройство или маршрутизатор и т.д.

Для того чтобы определить какие порты заблокировать, а какие будут передавать данные, выполняется алгоритм STA, и состоит он из следующих последовательных шагов:

1. Выбор корневого коммутатора (Root Bridge).
2. Определение корневых портов (Root Port).
3. Определение назначенных портов (Designated Port).
4. Блокировка оставшихся портов (Non-Designated Port).

Выбор корневого коммутатора (Root Bridge)

Итак, сначала выбирается, так называемый, корневой мост/коммутатор (Root Bridge). Root Bridge - это устройство (коммутатор), который STP считает центральной точкой для всех коммутаторов в сети, все дерево STP сходится к нему (поэтому он и называется корнем - root). Root Bridge будет отвечать за пересылку трафика в сети.

Выбор корневого моста основан на таком понятии как идентификатор коммутатора (Bridge ID или сокращенно BID), который, напомню, передается в Configuration BPDU.

Bridge ID - это число длиной 8 байт (64 бита), которое по умолчанию в своем классическом варианте состоит из двух полей: Bridge Priority (2 байта или 16 бит) и MAC-адреса устройства (6 байт или 48 бит):

Рис. 8. Формат классического Bridge ID

По умолчанию Bridge Priority (приоритет) равен 32768 на всех коммутаторах и может принимать значения от 0 до 65535 (2^16).

Однако, как мы помним, STP разрабатывался еще в далекие времена, когда дизайн сетей не подразумевал использование VLAN, соответственно, строилось одно общее дерево для всех коммутаторов. Поэтому позднее сначала Cisco в своем проприетарном PVST протоколе, а затем и IEEE в стандарте 802.1t-2001 (который, скорее, являлся дополнением к 802.1D-1998, а затем добавлен в 802.1D-2004) переосмыслили этот момент и переработали формат Bridge ID (при этом сохранив совместимость с классическим STP), и в результате, в числе прочего (мы чуть позже рассмотрим, что еще поменялось в 802.1t) появилось такое понятие как “Extended System ID”, и появилась возможность добавлять его в Bridge Priority.

Поэтому формат Bridge ID в версиях STP, которые поддерживают работу с VLAN, стал выглядеть следующим образом:

Рис. 9a. Формат обновленного Bridge ID из 802.1t

Или если подробнее, то Bridge Priority стал выглядеть так:

Рис. 9b. Формат обновленного Bridge ID из 802.1t

Сетевые инженеры подумали, что отдавать на приоритет коммутатора 16 бит – слишком много. Это, по сути, позволит администратору распределить 65536 потенциальных Root коммутаторов, но такое количество в сетях явно будет излишним, поэтому на Bridge Priority оставили 4 бита, а остальные 12 бит оставили для Extended System ID (VLAN ID или mst instance в случае MSTP).

Понятно, почему 12 бит выделено под Extended System ID -  потому что максимально возможное количество VLAN - 4096 (2¹²).

Оставшиеся 4 бита были оставлены для Bridge Priority, который теперь мог принимать значения от 0 до 61440, причем только кратные 4096 (т.к. в определении приоритета остались играть роль только первые значащие 4 бита, что наглядно видно из рисунка выше).

Откуда получился такой диапазон? Bridge ID вычисляется по формуле: “4096*N + номер VLAN/mst instance”, где N - множитель, который может принимать значения от 0 до 15 (2⁴ = 16, т.к. осталось 4 бита под поле приоритета), и по умолчанию он равен 8 (то есть значение Bridge Priority все также по умолчанию 32768), потому что старший бит в Bridge Priority принимает значение единицы (1000₂ = 8₁₀).

Это и объясняет то, почему значения Bridge Priority должны быть кратны 4096 - по значению младшего бита в Priority, то есть могут принимать значения: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, 61440 (то есть 16 возможных значений, как раз на 4 бита).

Вместе обновленный Bridge Priority и Extended System ID и образуют новый Bridge Priority в BID. В примере выше на картинке приоритет бы был равен 32768 + 1 = 32769 (priority + vlanid).

Однако, поле Extended System ID на сегодняшний день используется преимущественно только у Cisco. Кстати, добавление данного параметра в Cisco можно вообще отключить на некоторых платформах: ‘no spanning-tree extended system-id’. То есть этот параметр, по сути, необязательный и изначально был введен исключительно для Cisco PVST для учета VLAN.

К слову, в Cisco сначала появился протокол PVST (Per-VLAN Spanning Tree) - проприетарный протокол Cisco, который для каждого VLAN строит отдельное дерево (на Cisco нет как такового классического spanning-tree, только своя вариация). Однако PVST использовал инкапсуляцию только в ISL trunk. ISL (Inter-Switch Link) - это опять же проприетарный Cisco протокол, создан до появления dot1q (мало где используется, даже на самих Cisco). Поэтому позднее компания Cisco разработала улучшение для PVST - протокол PVST+, который позволяет инкапсулировать кадры с помощью стандарта IEEE 802.1Q. По умолчанию на всех коммутаторах Cisco работает PVST+. Эта информация может пригодиться нам, когда будем рассматривать взаимодействие мультивендорных протоколов spanning-tree с семейством проприетарного PVST.

Однако мы немного отвлеклись, в STP/RSTP мы не встретим добавление номера VLAN в расширенном Bridge Priority, так как это реализовано только в тех версиях STP, которые поддерживают работу с разными VLAN (у нас для работы с VLAN будет MSTP, но о нем позднее), поэтому данный параметр используется в основном только в протоколах, которые умеют работать с VLAN, а в обычных версиях STP/RSTP, параметр Extended System ID всегда, как правило, принимает нулевое значение: даже если используется расширенный формат Bridge Priority и кадр инкапсулируется в 802.1Q, то в дампе мы все равно увидим что-то вроде: “Bridge System ID Extension: 0”. Многие вендоры, несмотря на то, что новый формат Bridge Priority был даже стандартизирован IEEE, используют 4 бита под Bridge Priority (то есть используют Priority кратные 4096) и оставляют 12 бит под VID, но не добавляют его к значению Bridge Priority.

Это было затронуто, опять же, для того, чтобы у читателя, который только начинает свое знакомство с STP, увидевшего в Интернете такие сущности как Extended System ID или приоритет по умолчанию 32769 вместо 32768, не возник ступор: что это и почему так, почему где-то по умолчанию priority 32768 без добавления VLAN, а где-то еще и VLAN почему-то добавляется.

Вернемся к нашему обычному Bridge ID (далее для простоты будем рассматривать стандартный BID, без расширения для VLAN) и выборам корневого коммутатора.

На рисунке ниже показан пример, как BID выглядит в дампе:

Рис. 10. Пример BID в BPDU

Сначала сверяется только Bridge Priority. Побеждает и становится корневым тот коммутатор, у которого Bridge Priority меньше (например, 4096 выигрывает у 32768). Если приоритет одинаковый, то уже сравниваются MAC-адреса (Bridge System ID), и снова: у кого MAC-адрес меньше, тот и становится корневым. По умолчанию, у коммутаторов приоритет всегда 32768, поэтому в некоторых источниках и пишут, что BID выбирается именно по MAC-адресу коммутатора, но это не совсем верно. То, что именно MAC-адрес является ключевым фактором при выборе Root Bridge, происходит только если приоритет у коммутаторов одинаковый (что и бывает в большинстве случаев, если не менять вручную настройки приоритета).

В начале выборов каждый коммутатор считает себя корневым, о чем и заявляет всем остальным с помощью BPDU, в котором представляет свой идентификатор BID как ID корневого коммутатора - Root Bridge ID. В этом же BPDU каждый коммутатор передает свой BID и указывает, что Root Path Cost = 0, потому что считает себя корневым.

То есть после включения сети абсолютно все коммутаторы наводняют сеть своими Configuration BPDU, где Bridge ID = Root Bridge ID, и отправляются эти BPDU вообще со всех портов, ведь на Root коммутаторах все порты являются Designated, а Configuration BPDU отправляются именно через Designated-порты.

Рис. 11. Начало выборов Root Bridge

Если коммутатор получает BPDU, где Bridge ID больше, чем у него, то коммутатор отбрасывает этот BPDU и продолжает считать корневым именно себя. Если коммутатор получает BPDU от коммутатора с меньшим Bridge ID (Superior BPDU), то он перестает анонсировать информацию о том, что он корневой и начинает передавать BPDU коммутатора с меньшим Bridge ID, указывая свой BID, новый Root Bridge ID и новый Root Path Cost до этого Root Bridge. И так коммутаторы продолжают обмениваться BPDU, пока не решат единогласно, кто же будет Root коммутатором.

В итоге, корневым оказывается тот коммутатор, чей Bridge ID меньше всех.

Может быть такое, что при одинаковых приоритетах (например, везде настроен приоритет по умолчанию - 32768) корневым коммутатором может быть выбран самый старый и непроизводительный коммутатор, и тогда весь трафик пойдет через него, что может привести к определенным проблемам в работе сети. Поэтому лучше назначать приоритеты на устройствах вручную.

В STP после выбора Root коммутатора, только он продолжает рассылать мультикастом Configuration BPDU каждые 2 секунды. На Root Bridge все порты являются Designated, и находятся они всегда в состоянии Forwarding. Другие коммутаторы будут перенаправлять BPDU от корневого коммутатора, но сами они их перестают генерировать после сходимости сети.

Как уже было сказано ранее, Configuration BPDU отправляются только через Designated порты. Коммутаторы не перенаправляют BPDU от корневого коммутатора через свои Root или Non-Designated порты: с корневых портов не отправляются, потому что нет смысла отправлять BPDU обратно коммутатору, который его и сгенерировал, а с Non-Designated не отправляются, потому что такие порты находятся в состоянии Blocking, а при таком состоянии порта коммутатор не отправляет BPDU с него, а только принимает, но об этом позднее.

Роли портов в STP:

1. Root Port (корневой порт коммутатора) - порт для передачи трафика корневому коммутатору. Каждый “некорневой” коммутатор имеет только один корневой порт, выбранный из соображений минимальной стоимости пути.
2. Designated Port (назначенный порт сегмента) - “некорневой” порт коммутатора между сегментами сети, принимающий трафик из соответствующего сегмента. На “некорневом” коммутаторе может быть множество Designated портов, а вот в каждом сегменте сети Designated порт всегда один.
3. Non-Designated Port (“неназначенный” порт сегмента) - порт, не являющийся корневым, или назначенным. Передача данных через такой порт запрещена.

Определение корневых портов (Root Port)

После того, как в сети был определен коммутатор с ролью Root Bridge, каждый из остальных коммутаторов должен найти один и только один порт, который будет вести к корневому коммутатору. Такой порт называется корневым портом (Root Port). Он предоставляет единственный путь для данного коммутатора к корневому.

Корневой порт выбирается по следующим критериям (или, как их называют в англоязычной литературе - tiebreaker; при совпадении первого критерия, выбор происходит по следующему и т.д.):

• Наименьшего Root Path Cost (lowest root cost).
• Наименьшего Bridge ID соседа (lowest neighbor bridge ID).
• Наименьшего Port ID соседа (lowest neighbor port ID).
• Наименьшего локального Port ID (lowest local port ID).

Root Path Cost (RPC) - это общее значение стоимости всех линков до корневого коммутатора. Эта стоимость определяется суммой стоимостей всех линков, которые нужно пройти кадру, чтобы дойти до корневого коммутатора (lowest root cost). В свою очередь, стоимость линка определяется просто — по его пропускной способности (чем выше скорость, тем меньше стоимость).

Происходит выбор Root Port следующим образом:

• Корневой коммутатор посылает BPDU с полем Root Path Cost, равным нулю (ноль, потому что он и так корневой коммутатор, ему не нужно никуда добираться, как и напрямую подключенным к нему коммутаторам, ведь у них уже есть прямое подключение к Root Bridge).
• Ближайший коммутатор смотрит на скорость своего порта, куда BPDU пришел, и добавляет стоимость согласно таблице (если быть точнее, коммутатор смотрит не на скорость порта - speed, а именно на пропускную способность - bandwidth. Пропускная способность по умолчанию равна скорости на интерфейсе, но может быть изменена при необходимости отдельно).

Таблица 1. Рекомендуемая стоимость порта в STP (из 802.1D-1998) в зависимости от пропускной способности

Еще раз хочется подчеркнуть, что это именно рекомендуемые значения стоимости линков согласно стандарта, но настраивать cost можно и по своему усмотрению.

В стандарте 802.1t-2001 рекомендованные значения стоимости были изменены (позднее были перемещены вместе с RSTP в IEEE 802.1D-2004):

Рис. 12. Выдержка из стандарта IEEE 802.1t-2001

Стоимость портов в 802.1D была в 16-битном формате. Причем в стандарте указывалось, что именно стоимость path cost ограничивалась 16 битами, а вот стоимость до Root – уже 32 бита, потому что в BPDU под неё было выделено сразу именно столько. Это несоответствие было решено в 802.1t – теперь любой path cost имел 32-битный формат. Рекомендуемое значение cost в 802.t получается путем деления 20 000 000 000 bit/s на пропускную способность линка в kbit/s (либо просто 20 Tbit/s на пропускную способность линка).

Помимо прочего, в 802.1t, как мы уже знаем, изменился формат BID, был добавлен Edge тип порта и т.д.

Но мы опять отвлеклись (к тому же все это мы посмотрим, когда будем разбирать RSTP), вернемся к процессу выбора Root портов в классическом STP:

• Коммутатор указывает новое значение RPC перед отправкой BPDU своим соседям: это значение состоит из стоимости порта, с которого можно добраться до Root Bridge, то есть куда пришел BPDU от этого самого Root коммутатора и из значения RPC, которое было указано в полученном BPDU.
• Далее этот коммутатор, получивший BPDU с RPC 0, посылает данный BPDU нижестоящим коммутаторам, но уже с новым значением Root Path Cost в зависимости от пропускной способности интерфейса, который у него смотрит в сторону корневого (на котором получил BPDU), и далее по цепочке вниз.

Рис. 13a. Выбор Root Port на основе lowest root cost

На рисунке выше видно, что коммутаторы сообщают своим соседям, кто является Root Bridge, и сколько будет стоить добраться до него через них. При этом они просто прибавляют стоимость своего интерфейса, на котором получают BPDU, и передают его дальше. И если для каких-то коммутаторов выбор корневого порта будет очевиден, например, для SW2 корневым явно будет Gi1/0/1, потому что там cost 0, в то время как на Gi1/0/3 он видит, что ему анонсируют стоимость до Root Bridge - 8, значит добраться до корневого коммутатор будет стоить 12 (8 + стоимость порта, на котором получен BPDU). 4 (0 + стоимость порта, на котором был получен BPDU) в данном контексте явно лучше (т.к. стоит меньше), чем 12. То же самое и с коммутатором SW3. А вот для других коммутаторов выбор по RPC будет невозможен. Например, SW4 в данном контексте, получает одинаковые значения стоимости до Root Bridge, и как тогда ему выбрать, какой порт делать корневым?

Посмотрим, как определились корневые порты:

Рис. 13b. Выбор Root Port на основе lowest root cost

Как видим, на SW2 и SW3 корневые порты удалось выбрать без проблем по наименьшему RPC, а вот на SW4 на всех портах, с которых приходят BPDU - path cost одинаковый. Что же делать в таком случае?

Если стоимость линков до корневого коммутатора совпадает, то в ход вступает следующий tiebreaker, и выбор корневого порта происходит на основе меньшего Bridge ID соседа-коммутатора (lowest neighbor bridge ID). 

То есть, если RPC на одном коммутаторе одинаковый для разных портов, то корневым портом станет порт, к которому подключен сосед с наименьшим Bridge ID.

Рис. 14. Выбор Root Port на основе lowest neighbor bridge ID (при одинаковом RPC)

Если и Bridge ID коммутаторов до корневого коммутатора совпадает (например, в случае, когда между двумя коммутаторами два и более линка), то тогда корневой порт выбирается на основе меньшего Port ID соседа (lowest neighbor port ID).

На L2-коммутаторе при работающем STP у каждого порта свой уникальный номер (идентификатор Port ID). Port ID, например, 0х8019 (hex) = 128.25 (dec), где 128 - default port priority, a 25 - ifindex порта, который определяется на коммутаторе. Причем, Port ID, как и в случае с Bridge ID, смотрится на другом конце линка (то есть не на локальном коммутаторе, а на соседе-коммутаторе, откуда получаем кадры на наш локальный коммутатор, где и происходит выбор Root port).

Рис. 15. Выбор Root Port на основе lowest neighbor port ID (при одинаковом RPC и BID)

Но что если и на этот раз у нас не получилось выявить победителя? Например, на нашем локальном коммутаторе есть два порта, которые подключаются в хаб, линки от которого в свою очередь идут в сторону другого коммутатора. Тогда у нас будет одинаковый neighbor port ID на локальном коммутаторе, соответственно нужен еще один tiebreaker для выбора корневого порта.

Поэтому последний критерий при выборе - lowest local port ID, это порт с наименьшим ID на нашем локальном коммутаторе.

Рис. 16. Выбор Root Port на основе lowest local port ID (при одинаковом RPC, BID, neighbor port ID)

Однако в современных сетях выбор по такому критерию маловероятен, т.к. хабы сейчас практически нигде не используются, но все равно не стоит забывать об этом.

Что важно запомнить:

• Root Port находится всегда в состоянии Forwarding.
• На линке напротив Root-порта (т.е. на коммутаторе соседе) ВСЕГДА должен быть Designated-порт, потому что путь до корневого коммутатора не может быть заблокирован.
• В сегменте всегда должен быть Designated-порт, чтобы принимать трафик, но наоборот - необязательно (порт напротив Designated может быть и заблокирован, а не быть Root).

Определение назначенных портов (Designated Port)

Далее выбираются назначенный (Designated) коммутатор в сегменте сети и соответственно назначенные (Designated) порты. Сегмент - это домен коллизий, т.е. если рассматривать коммутируемые Ethernet сети, то это, грубо говоря, патч-корд между коммутаторами. Либо это может быть несколько соединений (патч-кордов) между коммутаторами, например, при использовании хабов или общей шины в Ethernet.

Коммутатор в сегменте сети, имеющий наименьшее расстояние до корневого коммутатора, называется назначенным коммутатором или Designated bridge, а порт этого коммутатора, который подключен к рассматриваемому сегменту сети, является назначенным портом.

Назначенным (Designated) портом выбирается тот, который имеет лучшую стоимость до корневого коммутатора в данном сегменте. На “некорневом” коммутаторе всегда есть только один Root порт и при этом может быть множество Designated портов. А вот в каждом сегменте сети Designated порт всегда один.

Ранее мы уже упоминали, что у корневого коммутатора все порты являются Designated, и обычно это действительно так, но с некоторой оговоркой. Как мы уже сказали, что сегмент - домен коллизий, и в каждом домене коллизий будет выбран только один Designated порт. Но что если к корневому коммутатору двумя или более линками будет подключен хаб? Это будет означать, что порты корневого коммутатора находятся в одном сегменте (в одном домене коллизий), поэтому только один из них останется Designated, а остальные будут Non-Designated. Однако в современных сетях хабы практически не используются, поэтому и распространено говорить, что у корневого коммутатора все порты, как правило, являются Designated.

Так же, как и Root порт, Designated порт выбирается на основе определенных критериев в порядке очередности (tiebreakers):

• Наименьшего Root Path Cost коммутатора (lowest root cost).
• Наименьшего Bridge ID коммутатора (lowest bridge ID).
• Наименьшего локального Port ID (lowest local port ID).

 
Выбирается все именно относительно сегмента.

На примере рисунка ниже, рассмотрим, как сеть разделяется на сегменты:

Рис. 17. Разбиение сети на сегменты

На рисунке выше, каждый сегмент выделен в красный эллипс. Для каждого сегмента существует свой назначенный порт. В сегменте, где к коммутатору подключается какое-либо конечное устройство, порт коммутатора всегда будет Designated. Также, как правило, у корневого коммутатора все порты назначенные (только если к нему не подключен хаб). Данные порты мы уже можем точно определить как Designated.

А вот как определять остальные назначенные порты для каждого сегмента описано в алгоритме выше.

Lowest Root Path Cost не означает, что Designated порт будет выбран на основе наименьшего RPC на этом линке, рассматривается именно RPC на каждом коммутаторе в сегменте, где мы и выбираем Designated порт. То есть, назначенным портом в сегменте будет выбран тот, на коммутаторе которого наименьшее значение стоимости path cost до Root Bridge.

Рис. 18. Выбор Designated портов на основе RPC

Если Root Path Cost коммутаторов одинаковый, то Designated порт будет определен на основе меньшего BID в сегменте (DP будет выбран на коммутаторе с наименьшим BID).

Рис. 19. Выбор Designated портов на основе BID

Если и BID в сегменте одинаковые (т.е. если это один коммутатор), то Designated порт будет выбран по наименьшему Local Port ID.

Рис. 20. Выбор Designated портов на основе local port ID

Также Designated выбираются порты, с которых не приходят BPDU, т.е. коммутатор понимает, что за данным портом находится какое-то конечное устройство (например, ПК, телефон, сервер, которые не умеют отправлять BPDU), и он спокойно переводит его в состояние Forwarding, т.к. нет риска возникновения петли.

И также, как мы уже говорили, Designated-портом обязательно будет порт напротив Root порта в сегменте.

И вот уже после того, как выбраны корневые и назначенные порты, оставшиеся порты становятся Non-Designated и блокируются, таким образом разрывая петлю. Заблокированный порт может продолжать принимать кадры, но не будет их никуда перенаправлять, также он продолжает слушать BPDU (т.е. важно понимать, что STP не отключает линк полностью, потому что BPDU должны продолжать отправляться на случай изменения топологии, не передается только data трафик).

Рис. 21. Блокировка оставшихся Non-Designated портов

Подводя итог, еще раз сравним для понимания Root и Designated-порты. Root порт-выбирается на коммутаторе для ОТПРАВКИ трафика корневому (Root) коммутатору, или в его в сторону (поэтому на корневом коммутаторе и нет Root портов), и на данном коммутаторе, где выбирается Root порт, этот Root порт является ближайшей точкой выхода (кратчайший путь до Root Bridge), чтобы добраться до корневого коммутатора. А Designated порт, ПРИНИМАЕТ этот трафик в сегменте (который был отправлен через Root порт предыдущего коммутатора), чтобы в конечном счете трафик дошел до корневого коммутатора, и опять же по кратчайшему пути (именно поэтому на корневом коммутаторе все порты Designated, и он сам будет являться Designated Bridge в сегменте, потому что имеет “лучший путь” до самого себя во всех сегментах).

Таймеры STP и изменение топологии

В STP существуют следующие состояния портов:

• Disabled - отключенный порт. Порт, выключенный административно (командой shutdown или вследствие errdisabled). Данный порт ничего не передает и не принимает: ни пользовательский трафик, ни BPDU. MAC-адреса, разумеется, не изучает.
• Blocking - блокирование. Данное состояние предназначено для предотвращения петель в сети. Однако, это не означает, что порт будет неактивен: STP не может выключать этот линк полностью. Блокированный порт все равно слушает и принимает BPDU (хоть сам и НЕ отправляет), так как ему нужно быть готовым перейти в другое состояние в случае работы алгоритма STA. MAC-адреса он НЕ изучает. Кадры с данными также НЕ перенаправляет;
• Listening - прослушивание. Порт слушает и начинает сам отправлять BPDU (только Designated порт). MAC-адреса НЕ изучает. Кадры с данными НЕ перенаправляет;
• Learning - обучение. Порт слушает и отправляет BPDU (отправляет только Designated порт), а также вносит изменения в CAM-таблицу (начинает изучать MAC-адреса, по трафику, который приходит на порт). Данные НЕ перенаправляет;
• Forwarding - пересылка. Порт слушает/отправляет BPDU (отправляет только Designated порт), участвует в поддержании таблицы MAC-адресов и перенаправляет данные. То есть это обычное состояние рабочего порта.

 
Blocking и Forwarding - стабильные состояния, а Listening и Learning - промежуточные. 

Если порт изменяет состояние с Blocking в Forwarding, то он должен пройти через два промежуточных состояния: Listening и Learning. Переход из Forwarding в Blocking может выполняться сразу.

Root/Designated порты всегда должны оставаться в стабильном состоянии Forwarding (если только не происходит изменение топологии).

Non-Designated порты всегда остаются в стабильном Blocking состоянии.

Работа классического протокола STP основа на таймерах.

Как мы уже рассматривали выше в структуре BPDU, в STP существуют следующие таймеры:

• Hello Time - интервал отправки Hello BPDU. Это интервал, через который посылаются пакеты BPDU с Root Bridge. По умолчанию - 2 секунды, но можно редактировать;
• Forward Delay - задержка смены состояний. Определяет время, как долго Root или Designated порты коммутатора будут оставаться в состоянии Listening и Learning. По умолчанию - 15 секунд. Можно еще сказать так, что Forward Delay - это время, за которое информация в BPDU гарантированно будет передана от любого коммутатора в топологии до любого другого. Далее будет понятно, почему так можно толковать этот таймер;
• Max Age - максимальное время жизни сообщения. Показывает, когда текущий Hello BPDU устареет и должен быть удален. По умолчанию - это 20 секунд (10*Hello Time). Если кадр BPDU имеет время жизни, превышающее максимальное, то кадр игнорируется коммутаторами. Таймер обнуляется при получении BPDU. Если текущий Hello BPDU устарел, но новые BPDU не приходят (таймер не обнуляется), то коммутатор восстанавливает резервный линк.

При включении устройства с STP (или при подключении нового патч-корда) все порты проходят вышеприведенные состояния именно в таком порядке (за исключением состояния Disabled). Ведь при включении на другом конце патч-корда, который только что подключили в порт, может быть коммутатор, на котором может присутствовать потенциальная петля. Вот поэтому порт сначала 15 секунд по умолчанию (Forward Delay таймер) находится в состоянии прослушивания (Listening) - он смотрит BPDU, попадающие в него, выясняет свое положение в сети. Потом порт переходит к обучению еще на 15 секунд (снова таймер Forward Delay) - порт смотрит какие MAC-адреса есть на линке, и записывает в свою таблицу коммутации все MAC-адреса из кадров, поступающих на порт (Learning), и потом, убедившись, что все в порядке, начинает уже свою работу (Forwarding). Итого, мы имеем целых 30 секунд простоя, прежде чем подключенное устройство сможет обмениваться информацией со своими соседями.

Как известно, Root коммутатор отправляет Configuration BPDU каждые 2 секунды (Hello Time). И эти BPDU транслируют все коммутаторы через свои Designated порты. В STP у коммутаторов есть такой таймер, как Max Age. По умолчанию - это 20 секунд (10*Hello Time). Если кадр BPDU имеет время жизни, превышающее максимальное, то кадр игнорируется коммутаторами. Таймер обнуляется (точнее сбрасывается снова до 20 секунд по умолчанию) при получении BPDU. Например, Root Bridge отправил Hello BPDU, он пришел на коммутатор, коммутатор начинает отсчитывать по умолчанию 20, 19, 18 ... Затем, поскольку прошло 2 секунды (Hello Time), Root Bridge снова отправляет Hello BPDU, и при его получении коммутатор начинает отсчитывать заново: 20, 19, 18 ...

Если вдруг коммутатор перестает получать Hello BPDU от Root Bridge, то спустя интервал Max Age, когда отсчет дошел уже до нуля, и если Hello BPDU не пришел на коммутатор, то коммутатор восстанавливает резервный линк. Для этого он заново “проводит выборы” STP: выбор корневого коммутатора, выбор Root, Designated и Non-Designated портов.

Если бывший Non-Designated порт после выборов станет Root или Designated портом, то из состояния Blocking, он должен будет перейти в Forwarding, через несколько промежуточных состояний согласно всем таймерам. И в конце концов ранее заблокированный порт становится Root или Designated портом, а другой порт блокируется. Итого, если коммутатор перестает получать BPDU, то он не сразу реагирует и не будет сразу же стремиться изменить топологию STP, поэтому у нас будет около 50 секунд простоя до полного перестроения топологии: 20 + 15 + 15 (Max Age + Forward Delay + Forward Delay), что есть, несомненно, долго в современных реалиях.

Однако, Max Age таймер не всегда “вступает в игру”. Например, если падает линк между коммутаторами, и коммутатор видит, что его Root порт теперь недоступен, соответственно он не знает, как теперь добраться до корневого коммутатора, но при этом он продолжает получать BPDU через Non-Designated порт, то он сразу же, не дожидаясь окончания таймера Max Age, меняет роль порта с Non-Designated на Root порт, и проходит через состояния Listening —> Learning —> Forwarding. То есть, процесс занимает 30 секунд вместо 50.

А вот если бы после падения линка перестали приходить BPDU на Non-Designated порт другого коммутатора, то тут как раз бы и “вступил в игру” таймер Max Age и простой в таком случае составит 50 секунд. 

Вот поэтому и говорят, что в классическом STP простой составляет от 30 до 50 секунд, в зависимости от ситуации.

Вообще, Max Age по умолчанию - 20 секунд. Однако время, при котором BPDU устаревают, зависит от того, как далеко коммутатор находится от корневого. Когда коммутатор получает BPDU он вычитает значение Message Age из Max Age таймера. Message Age (время жизни сообщения) - количество времени, прошедшее с того момента как Root Bridge отправил BPDU (аналогично полю TTL в IP-пакете). Root коммутатор устанавливает значение 0, и это значение увеличивается на один каждый раз, когда BPDU проходит через какой-то коммутатор на своем пути. То есть, на коммутаторе за корневым Message Age будет 1, на следующем коммутаторе будет 2 и т.д., поэтому на коммутаторе за корневым, BPDU истечет через 20 секунд (20-0=20), на следующем коммутаторе устареет через 19 секунд (20-1=19) и т.д.

Все таймеры, установленные на Root Bridge: Hello Time, Forward Delay, Max Age, определяют таймеры во всей сети (т.е. на всех остальных коммутаторах).

Изменениями топологии в STP считается изменения ролей DP и RP, а именно:

• когда какой-либо порт переходит в состояние Forwarding;
• когда порт в состоянии Learning или Forwarding переходит в состояние Blocking или Disabled.

Если, например, Non-Designated порт станет Designated, то это не послужит триггером для оповещения о смене топологии, по крайней мере не сразу. Потому что, как было сказано ранее, триггером для определения смены топологии служит переход в состояние Forwarding, либо переход из состояний Learning или Forwarding в состояние Blocking или Disabled. А смена ролей с Non-Designated на Designated, это в первую очередь переход из состояния Blocking в состояние Listening, а это не является триггером для отправки сообщений, что топология поменялась.

“Некорневой” коммутатор, который обнаружил изменения в топологии, например, один из портов перешел в состояние Disabled (shutdown). отправляет Topology Change Notification (TCN) BPDU корневому коммутатору через свой Root порт.

Когда мы рассматривали формат TCN BPDU ранее, то убедились, что в нем нет информации о том, что именно и где изменилось, коммутатор просто сообщает что где-то в топологии произошли какие-то изменения.

Отправка TCN сообщения повторяется каждый Hello interval (2 секунды по умолчанию) до тех пор, пока получение сообщения не будет подтверждено, но обычно подтверждение приходит практически мгновенно, поэтому, как правило, коммутатор успевает отправить только один TCN BPDU.

Следующий коммутатор, который получил TCN BPDU, как правило, сперва также отправляет TCN BPDU через свой Root порт, и только потом отправляет назад подтверждение в ответ на предыдущий TCN, который он сам получил. Дело в том, что нужно как можно скорее уведомить корневой коммутатор об изменении топологии, поэтому отправка TCN BPDU имеет приоритет перед подтверждением. Но это зависит опять же от реализации spanning-tree на коммутаторе.

Подтверждение отправляется в следующем Configuration BPDU, которое будет отправлять коммутатор, выставлением флага TCA (Topology Change Acknowledgement).

Рис. 22. Отправка BPDU с флагом TCA

Далее коммутаторы, у которых порт работает в роли DP для сегмента, повторяют первые два шага и отправляют TCN BPDU через свой корневой порт и ждут подтверждения.

После того, как корневой коммутатор получил TCN BPDU, он также отправляет сообщение о получении с флагом TCA, а затем начинает отправлять Configuration BPDU с установленным флагом TC (Topology Change), уже без флага TCA. Корневой коммутатор продолжает отправлять эти сообщения в течение Max Age таймера + таймера Forward Delay (20+15 = 35 секунд по умолчанию).

Рис. 23. Отправка BPDU с флагом TC

Эти сообщения получают все коммутаторы. При получении сообщения Hello BPDU с флагом TC, коммутатор использует таймер (Forward Delay time), для того чтобы обновить записи в таблице коммутации. Для этого после получения сообщения с флагом TC он изменяет время жизни MAC-адресов (MAC Address Aging Timer) со значения по умолчанию (обычно, это 300 секунд, но в зависимости от вендора может быть по-разному) до 15 секунд (как раз на величину таймера Forward Delay). MAC-адреса устройств, которые никак не взаимодействуют ни с кем, удаляются из таблицы коммутации по истечении 15 секунд, а MAC-адреса активных устройств останутся в таблице.

Обновление выполняется из-за того, что после изменений в топологии STP, в таблице коммутации могут храниться неправильные записи. Поэтому, чтобы устройства могли общаться между собой после изменения топологии и используется Forward Delay таймер (15 секунд), в противном случае без немедленной очистки записей придется ждать 5 минут (300 секунд, значение по умолчанию), пока время жизни записей в таблице коммутации не истечет, и коммутатор только тогда узнает за каким портом теперь находится получатель (после перестроения топологии), за счёт отправки unknown-unicast сообщения. Да, сходимость STP будет все также до 50 секунд, однако это лучше, чем невозможность устройств общаться между собой в течение 5 минут.

STP Toolkit

Говоря об STP (впрочем, как и о любой другой сущности в сетевых технологиях), не стоит забывать о безопасности. Дело в том, что в самом алгоритме spanning-tree нет никакой проверки аутентификации или проверки от кого именно пришел BPDU-пакет, чем легко могут воспользоваться злоумышленники. Поэтому в STP есть полезный функционал или расширение, который иногда также называют STP Toolkit (в терминологии Cisco), он позволит обеспечить дополнительную защиту при использовании STP, а также содержит дополнительный функционал, который может быть полезен при определенных условиях.

В него входят:

• Portfast.
• BPDU Guard / BPDU Filter.
• Root Guard / Loop Guard.
• и т.д. (есть еще функционал, который входит в STP Toolkit, но мы рассмотрим наиболее популярный).

  
 1. Portfast.

На коммутаторе при использовании STP можно применить на порту режим portfast. Данный режим позволяет переводить порт сразу же в состояние Forwarding, минуя Listening и Learning (то есть без простоя в 30 секунд). Причем несмотря на это, порт все равно будет слушать приходящие BPDU.

Данный режим можно включать на портах, к которым подключены конечные устройства, и также, на некоторых вендорах (например, на Cisco) это не будет работать на trunk портах (только на access, потому что другие коммутаторы подключаются, как правило, через trunk порты).

На портах, к которым подключаются другие коммутаторы, данный функционал включать крайне не рекомендуется, так как есть риск возникновения петли.

Также риск и есть даже при включении portfast на портах, куда подключены конечные устройства. Что если, кто-то вместо конечного устройства, пусть даже непредумышленно, подключит коммутатор и соединит порты, где было прописано portfast в этот коммутатор. Образуется петля.

  2. BPDU Guard / BPDU Filter.

Также на порту можно включить BPDU Guard, и если на данный порт придет STP BPDU, то интерфейс будет заблокирован для предотвращения образования петли (err-disabled). Также функционал может использоваться для защиты от злоумышленников, которые, отправляя BPDU, хотят выдавать себя за Root коммутатор, чтобы перехватывать весь трафик, либо просто хотят сделать сеть неработоспособной из-за бесконечных перестроений, так как коммутаторы будут постоянно получать TCN BPDU и будут реагировать на них.

BPDU Filter имеет схожий функционал, но не отключает порт, а просто отбрасывает все BPDU (как на IN, так и на OUT). 

  3. Root Guard / Loop Guard.

Если на порту применить функционал Root Guard, то даже при поступлении superior BPDU (с меньшим BID), коммутатор не будет воспринимать данный коммутатор как новый Root Bridge, а просто заблокирует интерфейс. Это позволит поддерживать, точнее даже удерживать топологию STP, как нам необходимо. Функционал будет полезен, например, если какой-либо злоумышленник захочет включить еще один коммутатор в топологию и сделать его корневым, чтобы весь трафик шел через него.

Loop Guard же позволяет не переводить порт в состояние Forwarding, даже если коммутатор перестал получать BPDU на этом порту. То есть коммутатор при отсутствии BPDU может посчитать, что там находится теперь не коммутатор, а, вероятно, какое-то конечное устройство, значит можно разблокировать порт. А на деле, например, по какой-то причине данные на линке перестали передаваться в одну сторону, т.е. линк стал однонаправленный, поэтому BPDU и не проходят. Поэтому если применить Loop Guard на порту, то когда при отсутствии BPDU порт попытается перейти в Forwarding, он будет сразу же заблокирован.

RSTP (802.1w, Rapid Spanning Tree Protocol)

Как мы уже заметили ранее, время сходимости STP было очень большим, даже в контексте того времени. 50 секунд простоя - целая вечность, особенно в масштабе современных сетей. Поэтому нужна была какая-то альтернатива, которая не заставила себя ждать. Так впервые в 2001 году появился протокол RSTP (из названия “Rapid” можно догадаться, что этот протокол должен работать гораздо быстрее).

RSTP впервые был описан в стандарте IEEE 802.1w-2001, затем он перекочевал в IEEE 802.1D-2004, где полностью заменил собой классический STP. В Cisco аналог мультивендорного RSTP называется PVRST+ (Per-Vlan Rapid Spanning Tree) или Rapid PVST+ (RPVST+). Rapid PVST+ в каждом VLAN строит дерево. В каждом VLAN работает RSTP.

RSTP vs STP. Изменения в BPDU, новые роли и состояния портов

Сразу же остановимся на основных отличиях STP и RSTP, а позднее рассмотрим их все подробнее:

Таблица 2. Сравнение ключевых особенностей в работе STP и RSTP

Рекомендуемая стоимость порта в RSTP (802.1w) в зависимости от пропускной способности линка (аналогична обновленной стоимости в стандарте 802.1t для классического STP, рассчитывается также по формуле: 20 Tbit/s / bandwidth):

Таблица 3. Рекомендуемая стоимость порта в RSTP в зависимости от пропускной способности

Состояния портов:

• Discarding - порт только получает BPDU: сам BPDU не отправляет, MAC-адреса не изучает, данные не перенаправляет. Заменяет Disabled, Blocking и Listening состояния из классического STP. Справедливее даже сказать, что Discarding объединил в себе Disabled и Blocking из STP, а Listening просто перестал использоваться и был удален;
• Learning - порт слушает и отправляет BPDU, а также начинает изучать MAC-адреса, данные НЕ перенаправляет;
• Forwarding - порт слушает/отправляет BPDU, участвует в поддержании таблицы MAC-адресов, данные перенаправляет.

Роли портов RSTP:

• Root - тот же корневой порт, что и в классическом STP;
• Designated - тот же назначенный порт, что и в классическом STP;
• Non-Designated делится на следующие:
  • Alternate - альтернативный путь к корневому коммутатору. Это, можно сказать, резервный ("лучший второй", хотя их может быть и несколько) корневой порт. Путь отличается от того, который использует Root порт. Регулярный трафик на порту блокируется. Порт находится в состоянии Discarding и принимает превосходящие (superior) BPDU от другого коммутатора (т.е. либо с меньшим RPC, BID или Port ID).
  • Backup - запасной/резервный путь в сегмент, предоставляющий сегменту линк к корневому коммутатору, большей стоимости (т.е. хуже), чем «Designated» порт. То есть, по сути, резервный ("лучший второй", опять же может быть несколько) Designated порт. Регулярный трафик на порту блокируется. Порт находится в состоянии Discarding и принимает превосходящие (superior) BPDU от другого интерфейса на одном коммутаторе, т.е. BID в BPDU один и тот же. Это происходит только если интерфейсы коммутатора объединены в один домен коллизий, например, через хаб или через общую шину, например, коаксиальный кабель. Однако такие технологии практически не используются в современных сетях, поэтому Backup порт встречается достаточно редко.

В концепции новых резервных портов RSTP и кроется одна из причин быстрого переключения в случае отказа. Вместо того, чтобы искать решение проблемы уже после того, как она случилась (причем делать это очень долго), все “пути отхода” нам уже известны заранее, еще до появления проблемы. Грубо говоря, в случае отказа основного линка, произойдет быстрое переключение на резервный линк, и для этого RSTP не нужно заново просчитывать топологию, он просто переключится на запасной, заранее просчитанный путь.

В RSTP есть только один тип BPDU: он называется “Rapid/Multiple Spanning Tree” (аналог Configuration BPDU в обычном STP) и имеет следующие поля:

• Protocol Identifier (Идентификатор протокола STP, 2 байта): 0x0000.
• Protocol Version Identifier (Версия протокола STP, 1 байт): 2 для RSTP.
• BPDU Type (Тип BPDU, 1 байт): 0x02 для Rapid/Multiple Spanning Tree.
• BPDU flags (Флаги, 1 байт): бит 0 (младший) - TC (Topology Change), бит 1 - Proposal, биты 2-3 - роль порта: 00 (0) - unknown, 01 (1) - Alternate/Backup, 10 (2) - Root port, 11 (3) - Designated port, бит 4 - Learning, бит 5 - Forwarding, бит 6 - Agreement, бит 7 (старший) - TCA (Topology Change Acknowledgement).
• Root Identifier (Идентификатор корневого коммутатора, 8 байт): Root Bridge Priority + Root Bridge System ID.
• Root Path Cost  (Расстояние до корневого коммутатора, 4 байта).
• Bridge Identifier (Идентификатор коммутатора, 8 байт): Bridge Priority + Bridge System ID.
• Port identifier (Идентификатор порта, 2 байта).
• Message Age (Время жизни сообщения, 2 байта).
• Max Age (Таймер - максимальное время жизни сообщения, 2 байта).
• Hello Time (Таймер - интервал отправки Hello BPDU, 2 байта).
• Forward Delay (Задержка смены состояний, 2 байта). Минимальное время перехода коммутатора в новое состояние. По умолчанию - 15 секунд. Используется при переходе из состояния Blocking в состояние Listening, и затем из состояния Listening в состояние Learning (используется на shared-портах вместо Proposal/Agreement механизма, либо если сосед поддерживает только классический STP).

Рис. 24. Пример дампа RSTP BPDU

Если на коммутаторе запущен классический STP (802.1D) и если к нему придет RSTP BPDU, то коммутатор не поймет, что с ним делать. Поэтому, если коммутатор, на котором запущен RSTP определит, что на другом конце линка к нему поступает BPDU формата 802.1D, он также начнет работать в режиме классического STP. Это было сделано для обратной совместимости STP и RSTP.

Также можно заметить, что в RSTP нет отдельного BPDU для анонсирования изменений в топологии (Topology Change Notification - TCN BPDU). Вместо этого протокол использует флаг Topology Change (TC) в обычном BPDU, для того чтобы указать на изменения, произошедшие в топологии. Однако, опять же, для обратной совместимости с коммутаторами, которые используют классический STP, коммутаторы, использующие RSTP, могут обрабатывать и генерировать TCN BPDU.

В RSTP, в отличии от классического STP, все коммутаторы генерируют и отправляют свои BPDU через Designated порты через каждый Hello Time. Благодаря этому быстрее может быть обнаружено изменение топологии.

В RSTP при изменении топологии коммутатор отправляет Configuration BPDU с установленным флагом TC, и, подобно классическому STP, его сосед отправляет назад подтверждение в Configuration BPDU с установленным флагом TCA. А затем сообщает об изменении топологии уже своим соседям.

Изменением топологии в RSTP считается только переход non-edge порта в состояние Forwarding (в STP, как мы помним, были немного другие критерии).

Новые типы линков

Ранее в STP, для того чтобы убедиться, что порт может участвовать в передаче данных, требовались таймеры, т.е. коммутатор пассивно ждал в течение назначенного времени, слушая BPDU. Ключевой особенностью RSTP стало введение концепции типов портов, основанных на режиме работы линка: full-duplex или half-duplex, типы портов point-to-point (p2p) или shared соответственно.

К p2p-порту обычно подключается только один коммутатор, т.е. это прямое соединение между двумя коммутаторами. Данные порты всегда работают в режиме full-duplex. Дополнительно не нужно обозначать порт как p2p, коммутатор сделает это самостоятельно. Однако все равно, при желании, можно указать на порту явно, чтобы он был point-to-point.

К shared-порту подключается один или несколько RSTP коммутаторов через хаб, либо одно или несколько устройств через тот же хаб. Shared-порты должны всегда работать в режиме half-duplex для избежания коллизий. Аналогично point-to-point типу порта, shared-порт не нужно настраивать вручную, коммутатор сам определит тип, но опять же, как и в случае с p2p-портом, shared-порт можно задать принудительно.

Также появилось понятие пограничного порта - edge-port (которое также появилось одновременно с этим в стандарте 802.1t), к которому, как правило, подключаются конечные устройства.

Вообще в RSTP есть два типа портов: Edge-port и Non-edge-port. Edge-port - порт, подключенный к конечному устройству (например, ПК, IP-телефон, сервер и т.д.), на котором отсутствует возможность создания петлевой структуры. Non-edge-port - “непограничный” порт, к которому подключаются другие коммутаторы, участвующие в топологии RSTP. Если конечное устройство подключается к коммутатору напрямую, то на коммутаторе edge-порт должен работать в режиме full-duplex и быть point-to-point (то есть порт является одновременно пограничным, и тип линка является point-to-point. Такой тип соединения называется edge p2p). Но если конечные устройства подключаются к коммутатору через хаб, то тип порта на коммутаторе будет также edge, ведь к нему подключаются конечные устройства, но в то же время он будет shared и будет работать в режиме half-duplex, т.к. к нему подключен хаб (такой тип порта будет edge shared).

Как правило, Edge-порты назначаются вручную командой “spanning-tree portfast”, т.е. как в классическом STP настраивается режим portfast на порту. Коммутатор не умеет самостоятельно определять, кто к нему подключен. Конечно, он мог бы ориентироваться на наличие BPDU на этом порту, но по стандарту коммутатор должен обязательно подождать минимум 15 секунд (Forward delay таймер), прежде чем решить, что на его порт так и не пришло ни одно сообщение (а это слишком долго для RSTP), и при подключении устройств, Edge-порты сразу же, без какого-либо согласования, переходят из состояния Discarding в Forwarding, пропуская состояние Listening. Добавление/удаление edge-портов, или изменение их состояний никак не влияет на топологию: никаких перестроений не вызывает.

Shared-порты работают по старой схеме с прохождением через состояния Blocking - Listening - Learning - Forwarding, и поэтому в случае использования shared-порта преимущества использования RSTP отсутствуют. Однако, как уже было сказано множество раз в этой статье, в современных сетях хабы практически не используются, поэтому навряд ли мы встретим такой тип соединения.

А вот на p2p-портах (т.е. на портах между двумя коммутаторами) RSTP использует процесс предложения и соглашения: Proposal/Agreement. Коммутатор справедливо считает, что если линк работает в режиме полного дуплекса и не обозначен как пограничный, значит на нем только два устройства: он и другой коммутатор. И вместо того, чтобы ждать входящих BPDU, он сам пытается связаться с коммутатором на другом конце линка с помощью специальных Proposal BPDU (обычный RSTP BPDU с установленным флагом Proposal), в которых есть информация о стоимости маршрута к корневому коммутатору. Коммутатор устанавливает флаг "Proposal" в RSTP BPDU для того чтобы предложить себя на роль выделенного (Designated) коммутатора в сегменте. Роль порта в Proposal сообщении всегда установлена в "Designated". Второй коммутатор сравнивает полученную информацию со своей текущей и принимает решение, о чем извещает первый коммутатор посредством Agreement BPDU (тоже обычный RSTP BPDU с установленным флагом Agreement). Коммутатор устанавливает флаг "Agreement" в RSTP BPDU для того чтобы принять предыдущее предложение. Роль порта в Agreement сообщении всегда установлена в "Root".

Рассмотрим данный процесс более детально.

Proposal & Agreement

Допустим, у нас есть некая топология без петель.

Рис. 25. Пример топологии в RSTP без избыточных линков

Мы подключили к коммутатору sw3 два конечных устройства, обозначили порты подключения как edge-порты, и поэтому коммутатор сразу же перевел их в состояние Forwarding.

Рис. 26. Пример топологии в RSTP без избыточных линков с добавлением endpoint устройств

Все работает как надо, все предельно просто.

Теперь представим, что мы добавили еще один коммутатор и подключили его двумя линками в нашу топологию.

Рис. 27. Добавили еще один коммутатор в RSTP топологию

Рассмотрим сначала линк sw1 - sw4.

При добавлении коммутатора в дерево, когда поднимается какой-либо линк, порты на этом линке сразу становятся Designated и переходят в состояние Discarding. Затем коммутатор sw1 отправляет со своего Designated порта (который находится в статусе Discarding) superior BPDU с установленным флагом Proposal. В данном BPDU коммутатор также анонсирует себя как Root коммутатор, сообщает стандартно Root Bridge ID, RPC и т.д. Тем самым коммутатор sw1 предлагает (proposal): “Привет, я корневой коммутатор, предлагаю, чтобы мой порт был Designated, а твой порт должен быть Root портом” (на самом деле, отправить BPDU с установленным флагом Proposal будут оба устройства, но, в конечном итоге, на Proposal будет отвечать inferior устройство, т.к. будет видеть, что полученный BPDU соседа - superior).

Рис. 28. Отправка BPDU с установленным флагом Proposal

Когда коммутатор sw4 на другом конце линка получает данный BPDU, он видит, что это superior BPDU, и он переводит свой порт (на котором он получил BPDU от Root Bridge) из Designated Discarding в Root Discarding.

Помимо всего прочего, когда inferior коммутатор получает Proposal на своем порту, прежде чем отправить какой-то ответ, он начинает процесс синхронизации. Сперва коммутатор переводит все свои non-edge порты в состояние Discarding (edge порты не блокируются!). Это нужно для того, чтобы уберечься от возможного образования петель в момент работы процесса Proposal/Agreement. Non-edge порты переводятся в Discarding именно на inferior коммутаторе.

Рис. 29. Начало процесса синхронизации для линка sw1-sw4

После того, как процесс синхронизации начался, коммутатор sw4 отправит ответ с установленным флагом Agreement в сторону Root Bridge (соглашение на предложение) и переводит свой порт из Root Discarding в Root Forwarding.

Рис. 30. Отправка BPDU с установленным флагом Agreement

Когда корневой коммутатор sw1 получает положительный ответ (agreement) на свое предложение (proposal), он переводит свой порт из Designated Discarding в Designated Forwarding.

Рис. 31. Синхронизация для линка sw1-sw4 закончена

После этого синхронизация для этого линка заканчивается (можно сказать, что синхронизация - это процесс, который инициализирует коммутатор при поступлении к нему BPDU с установленным Proposal битом. В этом процессе коммутатор переводит все non-edge порты в состояние Discarding и отправляет ответ на Proposal, который и запустил этот процесс, и это даже необязательно должен быть Agreement. Процесс заканчивается сразу же, как только коммутатору, который и запустил этот процесс, приходит ответ, и порты переходят в стабильное состояние).

А вот на коммутаторе sw4, где в результате процесса синхронизации мы перевели non-edge порты в Discarding, с этих портов начнут отправляться BPDU с флагом Proposal, т.е. так называемый “разрыв” топологии сместился с линка между коммутаторами sw1 и sw4, под коммутатор sw3, на следующий линк. И для этого линка точно также будет проходить процесс синхронизации, далее процесс сместится на следующий линк и т.д.

Однако, не всегда коммутатор будет отправлять в ответ на Proposal свой Agreement.

Рис. 32. Пример ситуации, в которой не будет отправлен Agreement в ответ на Proposal

Например, в данном случае, у нас на линках sw1-sw4, sw4-sw3 прошел процесс синхронизации и добрался до линка между коммутаторами sw3 и sw2. В ответ на Proposal от коммутатора sw3 коммутатор sw2 не отправит Agreement, т.к. он не согласен с данным предложением. У него уже есть лучший маршрут до корневого коммутатора, и Root порт у него уже выбран. Поэтому коммутаторы решают, что линк между ними будет заблокирован. Роли портов и кто будет заблокирован, выбираются стандартно: один из портов будет Designated Forwarding, а другой Alternate Discarding. На этом процесс Proposal/Agreement заканчивается. У нас получилась новая топология без петель.

Рис. 33. Процесс Proposal/Agreement завершен для новой RSTP топологии

Так как весь процесс теперь не привязан к таймерам, происходит он очень быстро. Как только мы подключили новый коммутатор, он практически сразу вписывается в общую топологию и приступает к работе, весь процесс занимает буквально доли секунд, т.к. опять же коммутаторы не ждут истечения каких-либо таймеров, а обмениваются сообщениями между собой очень быстро (но все зависит, конечно, еще и от топологии сети).

Как уже было сказано ранее, RSTP имеет обратную совместимость с STP.

RSTP в своей работе использует обычные STP таймеры в следующих случаях:

1. К порту подключается устройство, поддерживающее только классический STP. В этом случае порт коммутатора из режима работы RSTP переходит в режим STP. А значит проходит все стандартные для STP стадии: Blocking, Listening, Learning, Forwarding (в зависимости от того, с какими значениями корневого коммутатора и стоимости будет получен BPDU).
2. Коммутатор определил соединение как shared. В этом случае используются стандартные таймеры RSTP. Так как к такому порту подключено два и более коммутатора, задействовать механизм Proposal/Agreement невозможно.
3. Подключено устройство, не участвующее в STP, и на порту не задан тип edge. В этом случае порт пройдёт следующие стадии RSTP: Discarding (15 секунд), Learning (15 секунд), Forwarding. Таким образом, он перейдёт в режим передачи только через 30 секунд.

Итак, вкратце подытожим о принципах работы протокола RSTP в виде следующих тезисов:

1. В RSTP 802.1w по сравнению с классическим STP был изменен формат cost (который был позаимствован из 802.1t, вышедшего в том же году), изменен формат BPDU, был удален тип TCN BPDU, появились типы линков: point-to-point, shared и edge-порт, новые роли портов: Alternate (запасной корневой порт) и Backup (запасной Designated порт), появилось состояние Discarding, которое заменило Disabled, Blocking, Listening;
2. Несмотря на все это, RSTP сохранил обратную совместимость с STP. Если коммутатор на другом конце линка не умеет работать с RSTP, или если тип линка между устройствами shared, то RSTP будет работать по классическому алгоритму 802.1D со всеми таймерами и состояниями. В RSTP корневой коммутатор и роли портов, все выбирается аналогично;
3. Однако ключевое преимущество RSTP как раз-таки в том, что он не привязан к каким-либо таймерам, а работает за счет механизма Proposal/Agreement (на p2p линках);
4. Если коммутатор перестает получать BPDU (которые в RSTP отправляют все коммутаторы в сети, а не только корневой) от соседа в течение трех Hello Time (6 секунд по умолчанию), то он считает, что сосед “мертв”, уведомляет всех своих соседей путем лавинной рассылки BPDU с установленным TC флагом (и соседи делают тоже самое) и запускает перестроение топологии: бывший Alternate порт станет Root портом и запустит механизм Proposal/Agreement для определения состояний портов.

MSTP (802.1s, Multiple Spanning Tree Protocol)

MSTP впервые был описан в стандарте IEEE 802.1s (дополнение к 802.1Q) в 2002 году, а в последствии перекочевал в IEEE 802.1Q-2003.

MSTP работает по тому же принципу, что и RSTP (т.е. со всеми Proposal/Agreement механизмами и прочим), только теперь еще и с учетом VLAN.

Казалось бы, у нас есть усовершенствованный механизм STP (в лице RSTP), который в случае чего срабатывает мгновенно, зачем тогда нам еще нужен какой-то MSTP?

Изначально для защиты сетей с кольцевыми топологиями использовались STP и его модификация RSTP, которые строили единое для всех VLAN покрывающее дерево. Это было просто и удобно с точки зрения эксплуатации, но не позволяло гибко управлять трафиком, разнося разные VLAN по разным физическим каналам. С учетом того, что VLAN - достаточно удобный инструмент, который используется практически во всех современных сетях, такая технология построения дерева для разных VLAN была просто необходима.

К тому же, может быть и такое, что у нас петля существует только физически, а логически петли между коммутаторами нет, потому что на портах выданы разные VLAN, поэтому трафик кольцеваться не будет, но, к сожалению, классических STP/RSTP это не особо интересует, ведь они не умеют работать с VLAN.

Конечно, проблема гибкости была решена в проприетарных Cisco PVST и PVST+, которые создавали отдельный процесс построения покрывающего дерева для каждого VLAN. Данный подход был довольно прост с точки зрения эксплуатации и очень гибок, но, во-первых, это, все-таки, проприетарные протоколы, которые полноценно поддерживаются только на оборудовании Cisco, а, во-вторых, при большом количестве VLAN будет тратиться больше времени на расчет и построение топологии, а также мы можем столкнуться с переутилизацией CPU коммутатора из-за большого количества STP процессов: если, например, у нас существует 3000 штук VLAN на транковом порту, то именно столько BPDU и будет поступать на CPU коммутатора каждый Hello Time.

Так как трафик большинства VLAN использовал идентичные пути, смысла в разделении процессов STP для них не было, соответственно концепция протокола была доработана. Так появился более совершенный протокол Multiple Spanning Tree Protocol (MSTP), который абстрагируется от отдельных VLAN, а использует такие понятия как: instance и region.

Как мы уже сказали, MSTP строит дерево не для каждого VLAN, а для каждого MST Instance (MSTI).

Если переводить дословно с английского, instance - экземпляр, копия, образец, пример. То есть в MSTP, instance - некая сущность, которая может объединять в себе несколько VLAN, и для каждого MSTI будет свое дерево RSTP (своя RSTP топология) и своя копия трафика.

Новая концепция вызывала сложности в эксплуатации, так как было необходимо идентично конфигурировать соответствие VLAN-MSTI на всех коммутаторах. Для упрощения и поддержания обратной совместимости с STP и RSTP была разработана концепция регионов.

Регион MSTP может быть образован из нескольких смежных коммутаторов с одинаковыми MSID (MST Configuration Identification), можно сказать, с одинаковыми настройками, состоящими из:

• Имя региона MSTP.
• Ревизия конфигурации (некое значение, которое должно меняться при изменении конфигурации. Назначается и меняется вручную, но на практике этот параметр почти не используется и не изменяется).
• Дайджест соответствий VLAN-MSTI (маппинг VLAN к MST Instance).

Грубо говоря, каждый регион объединяет в себе коммутаторы, которые имеют одинаковые соответствия VLAN к Instance.

Соответствие VLAN-MSTI не передается в BPDU, потому что если данные вдруг будут переданы неверно, то коммутаторы будут находиться в разных регионах. Поэтому вместо этого, у коммутаторов условно есть некая таблица маппинга VLAN-MSTI, состоящая из 4096 ячеек (максимального кол-ва VLAN), где каждому VLAN будет соответствовать какой-то MSTI, и коммутаторы будут вычислять MD5-хеш от этого соответствия VLAN-MSTI и отправлять его соседям, и уже это значение будет сравниваться коммутаторами.

Если все параметры MSID (MST Config name, MST Config revision, MST Config digest) совпадают у коммутаторов, значит они будут находиться в одном регионе MSTP, но если хоть один из параметров будет не совпадать, то коммутаторы окажутся в разных MSTP регионах.

Существует два основных взаимодействия в MSTP:

1. внутри региона;
2. между регионами.

Взаимодействие внутри региона MSTP

Внутри каждого MST региона есть два типа instance:

• Internal Spanning Tree Instance (IST Instance).
• Multiple Spanning Tree Instance (MSTI).

IST (Internal Spanning Tree Instance, либо еще можно услышать такое определение как “контрольный instance”) - это специальная копия связующего дерева, которая, по умолчанию, существует в каждом MST-регионе и не может быть удалена. IST присвоен номер 0 (Instance 0). Только IST дерево внутри региона может отправлять и получать кадры BPDU, а также служит для управления топологией внутри этого региона. Все VLAN, настроенные на коммутаторах MST-региона, по умолчанию привязаны именно к IST.

Также, IST определяет Root Bridge для всего региона. Root bridge для IST называется Regional Root Bridge.

Именно посредством Regional Root Bridge в IST передаются кадры BPDU, через которые строится дерево для каждого instance. То есть, для снижения нагрузки на коммутаторы, все BPDU различных MSTI коммутатора объединяются в один BPDU, и рассылаются в instance 0, но не во всех остальных instance.

MSTI (Multiple Spanning Tree Instance) в отличии от IST включает в себя VLAN, которые были добавлены в него статически (вручную), и должен содержать как минимум один VLAN. MSTI существуют только в пределах региона.

VLAN, которые назначаются в MSTI, должны изначально существовать в IST из того же региона MST. Когда мы назначаем VLAN статически в MSTI, коммутатор сперва удаляет этот VLAN из IST, и только затем добавляет его в MSTI. Таким образом, можно назначить VLAN только одному MSTI в регионе.

В MSTP может существовать от 0 до 64 деревьев MSTI, точнее нулевой instance для IST, и от 1 до 64 для MSTI. То есть, всего 65 (ограничение стандарта). Но у каждого вендора это может быть реализовано по-разному, например, на Cisco на некоторых платформах может существовать всего до 16 MSTI (0 - IST, 1-15 - MSTI). Но максимальное кол-во для всех одно - 65.

В пределах одного региона, в плане блокирования портов и сходимости, MSTP повторяет принципы RSTP, на основе которого и работает. То есть в IST (Instance 0) выбирается свой корневой коммутатор внутри региона - Regional Root Bridge. Региональный корневой коммутатор выбирается по следующим критериям:

• Lowest External path cost to CIST Root bridge (минимальная стоимости пути до корневого коммутатора всей сети: тот коммутатор, у которого наименьший Root Path Cost до CIST Root Bridge и станет Regional Root Bridge);
• Lowest Regional Bridge Identifier (наименьший BID в регионе);
• Lowest CIST Bridge Identifier (из BPDU, полученного из региона, где находится CIST Root Bridge).

(понятия CIST и CST мы рассмотрим ниже).

Далее, строятся деревья внутри региона для IST и каждого MSTI. Для каждого MSTI точно так же выбирается свой региональный корневой коммутатор (он может совпадать с региональным коммутатором IST, но необязательно, и обычно называется просто, Root коммутатор для этого MSTI, либо Regional Root для этого MSTI, но главным региональным коммутатором все равно будет regional root именно в IST), и строится своя топология без избыточных линков.

Взаимодействие между регионами MSTP

На самом деле, в современных сетях достаточно редко используется концепция с несколькими регионами, по крайней мере в небольших сетях точно нет смысла разделять MSTP на регионы.

Однако все равно разбиение на регионы - это очень важная часть MSTP, и нужно понимать, как происходит взаимодействие между регионами, что мы и рассмотрим далее.

Для этого введем такие понятия как CST и CIST.

CST (Common Spanning Tree) - дерево, соединяющее между собой MST регионы и коммутаторы, на которых не запущен MSTP, а настроен, например, STP, RSTP и т.д.

CIST (Common and Internal Spanning Tree) - полное покрывающее дерево сети, объединяющее в себе CST и IST всех MST-регионов.

На первый взгляд не очень понятно, поэтому рассмотрим схему.

Рис. 34. Пример IST/CST/CIST топологий

На рисунке выше рассмотрено три разных региона. В каждом регионе строятся свои топологии: разные MSTI деревья, ну и, конечно, одно главное дерево внутри региона - IST. Для связи между регионами используется дерево CST (оно выделено красным). Ну а все вместе: IST+CST - это уже будет CIST дерево.

Для защиты топологий соединения различных регионов и отдельных коммутаторов строится общее покрывающее дерево (CST). Каждый регион MSTP представляется для CST как отдельный виртуальный коммутатор, и при взаимодействии с другими регионами для нас существует только дерево CST. Мы не показываем соседям в других регионах, что существует и происходит внутри нашего региона, нашу топологию.

Соответствия VLAN-MSTI (точнее хеш от этих соответствий) также не передаются за пределы региона. Поэтому даже если в соседнем регионе будет точно такое же соответствие, между ними не будет ничего общего, т.к. коммутаторы находятся в разных регионах.

Для взаимодействия с другими регионами с пограничных портов CST будут отправляться BPDU с одинаковым Root Bridge ID, с одинаковым sender Bridge ID, с одинаковым RPC и т.д., даже если BPDU отправляются разными коммутаторами в регионе, поскольку, как уже было сказано, регион представляется в виде одного большого виртуального коммутатора.

И само дерево CST функционирует по протоколу STP/RSTP.

В качестве корневого коммутатора для всей сети (т.е. CST + IST) выбирается CIST/CST Root Bridge (CIST Root Identifier). Выбирается CIST Root Bridge стандартно по наименьшему Bridge ID (либо наименьший приоритет, либо наименьший идентификатор - MAC-адрес).

Если этот CIST Root Bridge будет находиться внутри какого-то региона, то остальные коммутаторы в этом же регионе будут понимать, что среди них всех данный коммутатор будет являться CIST Root Bridge. А коммутаторы в других регионах просто видят данный регион как один виртуальный коммутатор, и этот виртуальный коммутатор и будет являться для них всех корневым (несмотря на то, что в этом регионе есть и другие коммутаторы).

В MSTP BPDU (подробно формат BPDU мы рассмотрим позднее) для CIST Root Identifier существует так называемый “внешний” RPC - “CIST External Root Path Cost”. Он показывает нам, сколько будет стоить добраться до этого единого корневого коммутатора в сети. Соответственно, если этот коммутатор находится внутри региона, то на всех MST-коммутаторах в этом регионе External Root Path Cost будет равен нулю, т.к. до него не стоит ничего добраться из этого же региона. А если же нам поступил BPDU от соседа (из другого региона), что добраться до CIST Root Bridge будет стоить нам столько-то, то опять же коммутаторы внутри региона ничего не прибавляют к значению External Root Path Cost, а передают его без изменений внутри региона (единственное, что прибавится сама стоимость пограничного интерфейса, на котором получили BPDU).

При передаче информации за пределы региона в BPDU также указывается CIST Regional Root Bridge (CIST Regional Root Bridge = Regional Root Bridge). Как мы уже разобрались, это корневой коммутатор для дерева IST в пределах одного региона. И как мы уже говорили, с какого бы коммутатора в регионе мы не отправляли BPDU за пределы этого региона, Regional Root Bridge всегда будет указан один и тот же.

Таким образом, для одного региона в BPDU, отправляемом соседям за пределы региона с разных коммутаторов, всегда будут одинаковые поля CIST Root Bridge (в BPDU просто Root Identifier), CIST External Root Path Cost (в BPDU просто Root Path Cost), CIST Regional Root ID (в BPDU это просто Bridge Identifier при взаимодействии между регионами). А вот CIST Port ID (Port Identifier в BPDU) может и отличаться, смотря с какого порта будет отправлен BPDU.

В дереве IST, как мы помним, корневым коммутатором является Regional Root Bridge. Расстояние до него в пределах региона указывается в CIST Internal Root Path Cost. Ну а CIST Bridge Identifier - это, по сути, указывается BID в IST того, кто отправил BPDU.

Единственное, что не дублируется в BPDU - Port ID. Поскольку в MSTP отправляется всегда одна BPDU вне зависимости от принадлежности к дереву, поэтому и поле Port ID нет смысла дублировать для разных деревьев.

Формат MSTP BPDU

Формат MSTP BPDU очень схож с форматом RSTP BPDU:

• Protocol Identifier (Идентификатор протокола STP, 2 байта): 0x0000;
• Protocol Version Identifier (Версия протокола STP, 1 байт): 3 для MSTP;
• BPDU Type (Тип BPDU, 1 байт): 0x02 для Rapid/Multiple Spanning Tree;
• BPDU flags (CIST) (Флаги, 1 байт);
• Root Identifier (CIST Root ID) (Идентификатор корневого CIST коммутатора, 8 байт);
• Root Path Cost (CIST External RPC)  (Расстояние до корневого CIST коммутатора, 4 байта);
• Bridge Identifier (либо это BID коммутатора, который непосредственно отправил BPDU (например, если коммутатор, не поддерживает MSTP), либо это Regional Root Identifier (при взаимодействии между регионами), 8 байт);
• Port identifier (CIST Port ID) (Идентификатор порта, 2 байта);
• Message Age (Время жизни сообщения, 2 байта);
• Max Age (Таймер - максимальное время жизни сообщения, 2 байта);
• Hello Time (Таймер - интервал отправки Hello BPDU, 2 байта);
• Forward Delay (Задержка смены состояний, 2 байта);
• Version 1 Length (Всегда нулевое значение, 1 байт);
• Version 3 Length (Размер MST Extension, 2 байта);
• MST Extension:
• Configuration Identifier (51 байт):
• MST Config ID format selector (1 байт);
• MST Config name (32 байта);
• MST Config revision (2 байта);
• MST Config digest (16 байт);
• CIST Internal Root Path Cost (расстояние до Regional Root Bridge внутри региона, 4 байта);
• CIST Bridge Identifier (на самом деле, это IST Bridge Identifier, 8 байт);
• CIST Remaining hops (кол-во коммутаторов, которые прошел BPDU между коммутаторами внутри региона. По умолчанию максимальное кол-во - 20, затем BPDU будет отброшен. 1 байт);
• MSTID (M-record, one per-instance) (N*16 байт).

Рис. 35. Пример дампа MSTP BPDU

Как видим, до начала поля MST Extension, MSTP BPDU очень трудно отличить от RSTP BPDU.

Но, исходя из описанного нами формата BPDU и из скриншота дампа, возникает ряд вопросов. Почему присутствуют такие расхождения: почему в описанном нами (да и не только нами, а много кем в сети Интернет) формате BPDU указывается CIST Root ID, а в дампе - это просто Root Identifier, почему у нас есть CIST External RPC, а по факту в BPDU - это обычный Root Path Cost, и т.д.?

Дело в том, как мы уже говорили, формат MSTP BPDU до поля “MST Extension” является полной копией RSTP BPDU для обратной совместимости с другими версиями протокола, и неудивительно, ведь MSTP основан на работе RSTP (например, между регионами используется уже знакомый нам RSTP со всеми его механизмами). И все, до поля “MST Extension”, по сути является CST и рассматривается это все как взаимодействие между регионами, ведь RSTP работает как раз между регионами. И для взаимодействия между регионами нужен CIST Root Bridge, поэтому описанный в BPDU “Root Identifier” - это не что иное как CIST Root ID, а Root Path Cost до него - это CIST External RPC. При взаимодействии между регионами Bridge Identifier будет на самом деле CIST Regional Root ID, потому что, как мы уже разбирали, при отправке BPDU за пределы региона в качестве BID отправителя будет всегда указан Regional Root ID, ведь BPDU отправляются именно в Instance 0, где и находится regional root. А вот все, что уже находится в “MST Extension” - это взаимодействие коммутаторов в пределах одного региона. Итого, в BPDU поля называются по-старому для обратной совместимости с другими версиями spanning-tree, но несут в себе немного иной смысл. И плюс, значения некоторых полей зависят от того, где передается BPDU - внутри региона или между регионами.

MSID добавляется к MSTP BPDU так, что сохраняется совместимость с STP и RSTP (поскольку сначала BPDU идет полностью идентичным RSTP, то и сохраняется обратная совместимость - STP и RSTP коммутаторы могут принимать и обрабатывать MSTP BPDU). При этом MSTP BPDU, отправленные разными коммутаторами одного региона, воспринимаются смежными STP/RSTP-коммутаторами как RSTP BPDU одного коммутатора. Таким образом кольцевая топология на разных коммутаторах по-прежнему поддерживается и в регионе MSTP сохраняется гибкость управления трафиком.

Совпадение полей MST Config name, MST Config revision, MST Config digest обозначает принадлежность к одному региону.

Роли портов в MSTP

Как мы уже заметили, MSTP по принципу работы очень схож с его прародителем - RSTP (ведь именно на RSTP и основана работа MSTP). Однако, несмотря на их схожесть, разумеется, есть некоторые различия, например, рассмотрим роли портов.

Как и в классическом STP/RSTP в MSTP существуют уже знакомые нам Root, Designated, Alternate и Backup порты. Однако, стоит заметить, что в MSTP роли портов для CIST дерева и для MSTI немного отличаются.

Итак:

1. CIST:

• Root - порт, предоставляющий наименьшую стоимость пути до CIST Root через regional root коммутатор;
• Designated - порт, предоставляющий к подключенному к нему сегменту сети самый дешевый путь до CIST Root коммутатора;
• Alternate - резервный корневой порт;
• Backup - резервный назначенный порт.

2. MSTI:

• Root - порт, предоставляющий наименьшую стоимость пути до regional root коммутатора (регионального в IST/MSTI).
• Designated - порт, предоставляющий к подключенному к нему сегменту сети самый дешевый путь до regional root коммутатора (регионального в IST/MSTI).
• Alternate - резервный корневой порт;
• Backup - резервный назначенный порт.

Также, в MSTP появилась новая роль - Master порт.

• Master - это порт с наименьшей стоимостью пути из региона до CIST Root коммутатора, который находится за пределами данного региона. Иными словами, если CIST Root находится в другом регионе, то в текущем регионе корневой порт на Regional Root Bridge будет master-портом. 
  Порт до CIST Root коммутатора на Regional Root Bridge будет являться master-портом для всех MSTI.
  Master-порт переходит в состояние Forwarding только тогда, когда внутри региона сошлись и синхронизировались все instance. Поэтому если в регионе будут постоянные перестроения топологии, может оказаться так, что регион будет изолирован от всей остальной топологии.
  И также появилась новая роль линков - P2p Bound, или пограничный линк.
  Тип Bound (или Boundary) присваивается тем портам, которые стоят на границе с другим регионом или другой разновидностью протокола STP, т.е. соединяют один MST регион с другим, или соединяют регион с коммутатором, на котором запущен не MSTP.

Topology change

Изменение топологии внутри какого-либо instance (IST/MSTI) влияет только на этот самый instance в пределах региона. Например, в instance 1 выданы VLAN 11, 12, 13, и произошло изменение топологии в 11 VLAN. В таком случае, все VLAN в instance (11, 12, 13) очистят свои таблицы коммутации.

При изменении топологии между регионами (CST), сообщения об изменении топологии распространяются между всеми регионами, но применяются только к boundary линкам.

Взаимодействие MSTP с проприетарными PVST+/RPVST+

Как и MSTP, проприетарные Cisco протоколы тоже умеют строить топологию для разных VLAN, позволяя балансировать трафик. Однако проблема в том, что это разные стандарты, и к тому же PVST может использоваться только на Cisco оборудовании. И в современном мире, наиболее вероятно, что в большинстве сетей используется оборудование не одного вендора, а самых разных. Поэтому необходимо как-то обеспечить взаимодействие между разными вендорами и их протоколами, как например, MSTP и PVST.

Возможно два варианта развития событий:

1. Root Bridge принадлежит MSTP (более предпочтительный вариант);
2. Root Bridge принадлежит PVST (более сложный и менее предпочтительный вариант).

Первый вариант является более предпочтительным, в то время как второй - более сложным и менее предпочтительным. Но в любом случае, оба варианта имеют право на существование. В сети Интернет можно найти множество статей о том, как можно организовать это взаимодействие, и объясняется, почему первый вариант более предпочтительный. Но тем не менее, везде есть свои нюансы (имеется в виду для оборудования разных вендоров). И в частности, как происходит взаимодействие между коммутаторами SNR и проприетарным PVST+ (Rapid PVST+) и все нюансы, мы рассмотрим позднее, поэтому сейчас не будем на этом останавливаться.

На этом можно завершить обзор протокола MSTP (и в целом обзор мультивендорных spanning-tree протоколов), все равно все нюансы рассмотреть не получится, как бы нам того не хотелось. Информации было очень много, поэтому опять же вкратце подытожим основные моменты:

1. MSTP в отличии от стандартных STP/RSTP умеет работать с VLAN, что позволяет добиться балансировки и гибкого управления трафиком;
2. Однако, в отличии от Cisco PVST+, дерево строится не для каждого VLAN, а для каждого instance. Соответственно появилась необходимость маппинга VLAN-MSTI, а для этого уже была разработана концепция регионов (которая редко где, но все равно используется);
3. Коммутаторы из одного региона должны иметь одинаковые параметры, в том числе тот же маппинг VLAN к MSTI. Внутри региона помимо пользовательских MSTI деревьев, существует основное дерево IST. Именно это дерево отвечает за прием и отправку BPDU со всех MSTI, и корневой коммутатор из этого дерева станет Regional Root Bridge для всего региона;
4. Для связи между регионами, а также коммутаторами, на которых запущен не MSTP, существует дерево CST. В данном случае, регион выступает как единый логический коммутатор. Взаимодействие будет вестись с Regional Root Bridge, а тот уже в свою очередь будет передавать данные всем в своем регионе;
5. Полное дерево CIST состоит из CST и IST. Для CIST точно также выбирается корневой коммутатор, который будет главным во всем сегменте сети;
6. Если CIST Root находится в отличном от нас регионе, то в нашем регионе корневой порт на regional root коммутаторе будет являться master портом - новая роль в MSTP.

Настройка и работа STP на коммутаторах SNR

Теперь, когда мы обладаем всеми необходимыми теоретическими знаниями, мы можем перейти к рассмотрению настройки и работы STP протоколов на коммутаторах SNR.

На всех линейках коммутаторов SNR существует поддержка всех типов мультивендорного spanning-tree: STP, RSTP, MSTP, и работает функционал везде одинаково, вне зависимости от чипсета и серии коммутаторов.

Однако, на серии S5210, в которую входят ТОРП-коммутаторы с российским программным обеспечением, есть свои небольшие нюансы, поэтому сперва мы рассмотрим настройку и работу на основных сериях коммутаторов SNR, а затем отдельно на серии с российским ПО - S5210.

Также есть и нюансы при взаимодействии коммутаторов SNR, где запущены мультивендорные протоколы защиты от петель, с коммутаторами вендора Cisco, где используются проприетарные протоколы.

Все это обязательно рассмотрим, но давайте по-порядку.

Настройка spanning-tree на основных сериях коммутаторов SNR
 

Настройка STP

По умолчанию на всех основных линейках коммутаторов SNR протоколы защиты от петель, в том числе и spanning-tree, отключены.

Чтобы их включить, необходимо в режиме глобальной конфигурации прописать “spanning-tree”:

Как видим, spanning-tree запустился, причем не STP, а MSTP.

По умолчанию на коммутаторах SNR включается именно MSTP, однако можно выбрать и другой режим, например, STP или RSTP:

После этого в текущей конфигурации увидим такие настройки:

Причем даже если бы мы выбрали сперва режим spanning-tree, отличный от MSTP, и только потом включили сам процесс spanning-tree, то у нас бы все равно было написано, что запущен MSTP, хотя на самом деле, в конфигурации и по факту будет тот режим, что мы выбрали.

Если бы был выбран режим MSTP, то это бы не отображалось в конфигурации, т.к. это режим по умолчанию, а все, что настроено по умолчанию, не отображается в конфигурации на коммутаторах SNR (обозначил явно, на всякий случай, т.к. в дальнейшем еще можем с этим столкнуться).

Например, это же касается и приоритета коммутатора. По умолчанию, как мы знаем, используется priority 32768, поэтому он и не отображается в конфигурации.

Но давайте попробуем назначить приоритет вручную, попробуем сделать так, чтобы этот коммутатор стал корневым.

И как помним, приоритет должен быть кратным 4096, мы рассматривали это в формате Bridge ID. Поэтому при попытке назначить значение некратное 4096, коммутатор выдаст ошибку и попросит выбрать корректное значение.

И после этого настройка приоритета появится в конфигурации:

К слову, после того, как мы включили глобально spanning-tree, он автоматически включается на всех портах.

Чтобы исключить какой-либо порт из spanning-tree домена необходимо в режиме конфигурации порта прописать: “no spanning-tree”.

Соберем простейшую схему из четырех коммутаторов:

Запустим на них STP и посмотрим, что получится.

Связности между коммутаторами нет (пока не соединили их патч-кордами), каждый считает себя корневым, и картина на всех будет примерно такая:

Теперь соединим коммутаторы патч-кордами, для простоты переименуем их в sw1, sw2, sw3, sw4, и посмотрим, как построится дерево STP:

sw1:

sw2:

sw3:

sw4:

Все коммутаторы обменялись BPDU, согласились с тем, что корневым будет коммутатор sw2, так как у него наименьший BID (засчет выставленного вручную priority).

Причем стоит обратить внимание, что MAC-адрес, который является частью BID, это CPU MAC коммутатора, а не VLAN MAC (можно увидеть это в выводе команды ‘show version’).

Давайте еще раз взглянем на схему, проверим, что алгоритм spanning-tree отработал верно.

Должна получиться такая топология. И, как видим, алгоритм spanning-tree на коммутаторах отработал именно так.

На что можно обратить внимание в выводе “sh spanning-tree”? Давайте быстро пробежимся по-порядку по всем полям этого вывода.

• “Standard”. Думаю, здесь и так все понятно, в данном поле указывается, какой именно тип spanning-tree мы используем;
• “Bridge MAC”. Здесь все так же предельно понятно - это MAC-адрес текущего коммутатора;
• “Bridge Times”. Таймеры, используемые spanning-tree;
• “Force Version”. Аналог поля “Protocol Version Identifier” в STP пакете (0 - STP, 2 - RSTP, 3 - MSTP);
• “Self Bridge Id”. Bridge ID текущего коммутатора (priority + MAC);
• “Root Id”. Bridge ID корневого коммутатора (priority + MAC). Может совпадать с “Self Bridge Id”, но тогда значения поля будет: “this switch”;
• “Ext.RootPathCost”. Стоимость пути до корневого коммутатора. В этом поле указывается наибольшее значение RPC, с “некорневого” порта;
• “Root Port ID”. Идентификатор корневого порта коммутатора;
• Далее идет уже сам вывод и распределение (топология) портов в STP. Единственное, что здесь стоит пояснить, на мой взгляд, последние два поля: “DsgBridge” и “DsgPort”. В них указываются Bridge ID (priority + MAC) назначенного коммутатора в сегменте (т.е. того коммутатора, который в сегменте ближе всего к корневому), и, соответственно, порт на нем. Отсюда нетрудно догадаться, что у корневого коммутатора будет указан его собственный BID и его же Port ID.

Внимательный читатель мог заметить, что в выводе “sh spanning-tree” используются такие поля как “Ext.RootPathCost”, хотя у нас не используется на данный момент MSTP, поэтому о каком внешнем RPC идет речь? Также сама стоимость этого RPC не соответствует стандарту 802.1D, а похожа скорее на 802.1t формат или RSTP. Также присутствует роль Alternate порта, хотя у нас классический STP. Bridge ID может принимать значения от 0 до 61440 и должен быть кратным 4096, т.е. новый формат BID присутствует даже в классическом STP 802.1D, и т.д.

Дело в том, что на коммутаторах SNR по умолчанию используется MSTP, поэтому остальные виды spanning-tree унаследовали некоторые особенности MSTP. Плюс ко всему сделано это для унификации и единообразия, которые позволяют добиться определенной совместимости с другими версиями spanning-tree и с другими вендорами, а также обеспечивает удобство работы, приводя все к одному виду.

Поэтому не нужно переживать, все работает согласно стандартам, хоть и может называться по-другому в классическом STP: ExtRootPathCost - обычный RPC, Alternate порт будет Non-Designated портом в состоянии Blocking. Да и формат path cost всегда можно поменять, для этого используется следующая команда:

Итак, мы без особого труда собрали схему и настроили классический STP на коммутаторах SNR. Рассматривать настройку и как работает RSTP на коммутаторах SNR нет особого смысла, т.к. для настройки достаточно сменить режим на RSTP: “spanning-tree mode rstp” на всех коммутаторах. Поэтому далее сразу перейдем к настройке MSTP.

Но для начала посмотрим, какие еще есть команды в режиме глобальной конфигурации, связанные с STP.

Команды spanning-tree из режима глобальной конфигурации

1. agreement-check-cancel.

Ключевой особенностью RSTP является механизм Proposal/Agreement. Мы выше подробно рассмотрели этот механизм в соответствующем разделе в RSTP. Однако стоит упомянуть, что существует два режима работы данного механизма:

• Common mode;
• Enhanced mode.

Common mode соответствует режиму работы, который мы описывали ранее. И поддерживается он как в RSTP, так и в MSTP.

А вот enhanced mode, как правило, можно встретить только в MSTP, и работает он немного иначе.

В enhanced mode сначала точно так же, как и в common mode, вышестоящее устройство (которое генерирует superior BPDU) отправляет предложение нижестоящему (inferior) устройству с установленным флагом Proposal, указывая, что порт, к которому подключается нижестоящее устройство, “хочет” как можно скорее перейти в состояние Forwarding. После этого нижестоящее устройство устанавливает порт, на котором получило BPDU, как корневой и блокирует все свои non-edge порты. Далее вышестоящее устройство отправляет второй BPDU, уже с флагом Agreement, и после этого нижестоящее устройство отвечает ему тоже BPDU с флагом Agreement. И тогда вышестоящее устройство переводит свой порт в Designated Forwarding, и на этом Proposal/Agreement заканчивается.

На коммутаторах SNR существует только enhanced метод, причем работает он и для MSTP, и для RSTP. И для совместимости с оборудованием, которое поддерживает и работает в режиме common mode, и используется функционал “agreement-check-cancel”.

Функционал, грубо говоря, отключает проверку флага Agreement, прежде чем отправить свой ответ. Поскольку на коммутаторах SNR используется enhanced метод, он будет ждать BPDU с флагами и Proposal, и Agreement, и только тогда будет отправлять свой Agreement в ответ. Но если он не получит Agreement, то не отправит свой ответ, соответственно механизм Proposal/Agreement будет невозможен, и сеть будет работать по алгоритмам классического STP. Но если применить данную команду, то коммутатор сможет отправить Agreement, даже если пришел Proposal без Agreement (т.е. как в классическом common mode).

2. cost-format.

Уже упоминали ранее такую команду. Она позволяет выбрать формат path cost: классический укороченный (из стандарта 802.1D - 16 бит), или новый (из стандарта 802.1t - 32 бита).

3. forward-time.

Установка значения таймера “Forward Delay Time” (задержка смены состояний). Как мы помним, данный таймер определяет время, как долго Root или Designated порты коммутатора будут оставаться в состоянии Listening и Learning. 

Данная ошибка говорит нам о том, что значение Forward Delay Timer, которое мы указываем, нельзя настроить, потому что иначе 2*(Bridge Forward Delay - 1) будет меньше, чем значение таймера Max Age. В противном случае мы не дождемся смены состояний, а BPDU просто устареет и будет отброшен.

4. hello-time.

Тут все просто. Это настройка интервала отправки Hello BPDU.

5. max-hop.

Установка значения счетчика Max-Hop в MSTP, который определяет какое количество коммутаторов может пройти BPDU, до того как будет отброшен.

6. maxage.

Это максимальное время жизни сообщения. Данный таймер показывает, когда текущий Hello BPDU устареет и должен быть удален.

7. mode.

8. mst.

Данная команда позволяет нам:

Чтобы выйти из настроек региона без сохранения изменений, используется команда ‘abort’.

Единственный нюанс: данный instance должен уже существовать на коммутаторе (то что мы как раз создавали в предыдущем подпункте в конфигурации региона), иначе команда не применится.

9. priority.

Если в предыдущем пункте была возможность настроить приоритет для какого-то определенного instance, т.е. для MSTP. То данная команда позволяет настроить приоритет для всего моста (т.е. для STP, RSTP, но также и для MSTP - приоритет будет задан для instance 0, т.к. это instance по умолчанию).

10. process.

Данный функционал используется в MSTP и позволяет разбить MSTP на несколько независимых процессов. В каждом процессе могут быть задействованы свои порты, и построена своя топология. Иными словами, очень гибкий функционал управления MSTP.

11. tcflush.

Установка режима перестроения топологии spanning-tree. Как было рассмотрено ранее, при перестроении топологии происходит очистка таблицы MAC-адресов. Да, это очень важно, однако не всегда и не во всех сетях требуется постоянно очищать записи при каждом изменении топологии. 

12. transmit-hold-count.

Значение по умолчанию - 200.

Посмотрим теперь, что есть интересного в режиме конфигурации порта.

Команды spanning-tree из режима конфигурации порта

1. spanning-tree.

При применении просто команды ‘spanning-tree’ в режиме конфигурации порта ничего не произойдет, потому что, как мы уже отметили ранее, по умолчанию, при включении spanning-tree в глобале, STP включается на всех портах коммутатора. То есть, ‘spanning-tree’ на порту - команда по умолчанию. А вот командой ‘no spanning-tree’ мы можем исключить порт из STP процесса. Таким образом, BPDU не будут отправляться на OUT в данный порт (т.к. порт исключен из STP домена). А если BPDU все-таки придет на порт, то он не будет обработан, а будет отброшен. А сам порт будет сразу же переведен в состояние Forwarding.

2. binding-process.

При просмотре настроек глобальной конфигурации мы упоминали о том, что в MSTP можно создать несколько независимых процессов. И каждый порт можно привязать к какому-либо процессу, что и делает данная команда.

3. bpdu.

По умолчанию BPDU отправляются нетегированными: без тега если access порт, или в native vlan, если порт в trunk. 

4. cost.

Здесь мы видим, что можно задать значение как из стандарта dot1d, так и из dot1t.

По умолчанию кост равен значению согласно пропускной способности порта, т.е. согласно стандарта.

Однако на коммутаторах SNR есть особенность, которая заключается в том, что на портах с пропускной способностью 10/100 мбит/с, по умолчанию значение согласно стандарту будет только в режиме работы линка half-duplex. Если режим работы линка будет full-duplex, то значение коста будет меньше на единицу. Это актуально и для старого (dot1d), и для нового формата (dot1t).

На таблице ниже это наглядно продемонстрировано. Найти эту таблицу можно также в наших command guide.

5. digest-snooping.

Включение/выключение аутентификации spanning-tree на порту. 

В протоколе MSTP используется концепция регионов. Мы уже рассматривали ранее, какие должны быть одинаковые параметры коммутаторов, чтобы они оказались в одном регионе:

• Имя региона MSTP;
• Ревизия конфигурации;
• Дайджест соответствий VLAN-MSTI (маппинг VLAN к MST Instance).

Но коммутаторы не передают и не сравнивают соответствие VLAN-MSTI, имя и т.д. Вместо этого они будут генерировать MD5-хеш от этих соответствий с публичным ключом аутентификации, этот хеш вместе с ключом будет передаваться соседям, и уже это значение будет сравниваться коммутаторами.

Однако некоторые вендоры не используют публичный ключ аутентификации, отсюда возникает несовместимость устройств, и они окажутся в разных регионах. Благодаря команде ‘spanning-tree digest-snooping’ на порту, будет копироваться хеш STP-соседа, находящегося за данным портом. И тогда устройства смогут оказаться в одном регионе.

6. format.

Установка формата BPDU.

standard - стандарт IEEE;

privacy - CIsco-совместимый формат;

auto - автоматическое определение формата по поступающим BPDU.

7. link-type p2p.

Выбор механизма определения типа подключенной к порту сети.

auto - автоматическое определение типа соединения;

force-true - всегда point-to-point;

force-false - всегда shared.

8. loopguard.

Функционал loopguard позволяет не переводить порт в состояние Forwarding, даже если коммутатор перестал получать BPDU на этом порту. При настройке loopguard на порту, если при отсутствии BPDU порт попытается перейти в Forwarding, он будет сразу же заблокирован.

9. mcheck.

Отслеживание режима подключенной сети и переключение на STP при необходимости.

По умолчанию данный функционал отключен и на порту используется MSTP. Если прописать данную команду на порту, то при получении на порту BPDU формата классического STP 802.1D, например, порт будет переведен в режим STP, но в противном случае, порт будет продолжать работать как MSTP порт.

10. mst.

По умолчанию все находится в нулевом mst.

11. port-priority.

Установить приоритет порта вручную.

Значение по умолчанию - 128.

SNR-S2982G-24TE(config-if-ethernet1/0/5)#spanning-tree port-priority ?

  <0-240>  Priority value <0-240>

12. portfast.

Здесь все предельно понятно: команда используется на портах подключения конечных устройств. Делается это для того, чтобы порт переходил сразу же в состояние Forwarding, минуя все промежуточные состояния.

По умолчанию portfast выключен.

13. rootguard.

Если применить данный функционал на порту, то даже при поступлении superior BPDU (с меньшим BID), коммутатор не будет воспринимать данный коммутатор как новый Root Bridge, соответственно порт делать корневым и пересчитывать топологию он не будет, а просто заблокирует интерфейс.

14. tcflush.

15. tcnguard / tc-guard.

В протоколе STP есть BPDU, которые рассылаются устройствами в случае обнаружения изменения в сети. Эти BPDU называются Topology Change Notification - TCN.

Некоторые сетевые инженеры не хотят, чтобы эти BPDU рассылались на каких-нибудь участках сети, чтобы сеть не перестраивалась и снова сходилась. 

И tcnguard, и tc-guard могут применяться только на выход с интерфейса (на OUT). На вход (на IN) фильтровать TCN/TC-flag невозможно, можно только с помощью различных ACL.

Теперь, когда мы рассмотрели все команды, можем переходить к рассмотрению MSTP на коммутаторах SNR.

Настройка MSTP

Топология у нас осталась та же самая, что и была при настройке STP.

Только теперь у нас везде настроен MSTP.

Посмотрим, как сошлось дерево spanning-tree.

sw1:

sw2:

sw3:

sw4:

Что изменилось по сравнению с выводом классического STP?

• версия протокола сменилась на MSTP (“Force Version: 3”);
• появилось разделение на instance;
• появились разделение на External RPC и Internal RPC, и с ними соответственно добавились поля Int.RootPathCost и IntRPC;
• появился идентификатор регионального коммутатора;
• появилось отображение принадлежности портов к instance.
   

Согласно выводам со всех коммутаторов они верно определили CIST Root Bridge, он же будет Regional Root Bridge, с чем коммутаторы также согласились. Коммутаторы попали в единый регион, ведь настройки у них у всех одинаковые, дефолтные. Поэтому ExtRPC у всех равен нулю, а работает здесь только IntRPC. Потому что, опять же, все находятся в одном регионе.

Теперь немного изменим конфигурацию так, чтобы коммутатор sw2, точно так же был CIST Root, но находился за пределами региона, и посмотрим, что изменится.

sw1:

sw2:

sw3:

sw4:

Давайте разберемся, что же тут вообще произошло.

То есть мы просто, создали еще один instance - MSTI1, тем самым изменив настройки региона, поэтому этот коммутатор и отделился от остальных.

Появился вывод информации для нового instance, и здесь точно так же описывается: кто является root bride, у кого какой идентификатор, cost и т.д.

Ну и поскольку мы ассоциировали порт 1/0/1 с VLAN 10, у нас в выводе “sh spanning-tree” порт 1/0/1 стал числиться сразу в нескольких instance.

Но MSTI1 нас не особо интересует, он был добавлен скорее для теста. Смотрим, что происходит в IST0.

Поскольку у коммутатора sw2 по-прежнему самый низкий приоритет, он будет являться Root Bridge, точнее CIST Root Bridge. И поскольку он теперь находится в отдельном регионе, и он там один, он же и будет для своего региона Regional Root Bridge. И все косты соответственно у него по нулям, ведь он является CIST и Regional Root.

Что касается IST0 для первоначального региона, CIST Root все признали sw2, что несомненно верно, не думаю, что тут нужны какие-то комментарии.

А вот Regional Root Bridge был выбран коммутатор sw1. Почему так?

Ранее мы рассматривали принцип выбора регионального коммутатора. Повторим еще раз, чтобы далеко не листать:

• Lowest External path cost to CIST Root bridge (минимальная стоимости пути до корневого коммутатора всей сети: тот коммутатор, у которого наименьший Root Path Cost до CIST Root Bridge и станет Regional Root Bridge);
• Lowest Regional Bridge Identifier (наименьший BID в регионе);
• Lowest CIST Bridge Identifier (из BPDU от региона с CIST Root Bridge).

Коммутатор sw1 выигрывает по косту и маку, именно поэтому он и выбран Regional Root Bridge.

И все остальные коммутаторы в регионе знают, как до него добраться, они указывают стоимость в поле “IntRPC”.

Но на самом деле, логически все выглядит как коммутатор sw1 подключенный к коммутатору sw2 (ведь мы помним, что коммутаторы одного региона представляют из себя один большой виртуальный коммутатор).

Такая схема маловероятна в современных сетях, но все же возможна. Мы просто рассмотрели простейшую настройку MSTP, а также как все будет выглядеть, если коммутаторы будут в одном регионе, или в разных.

Чтобы коммутаторы были в одном регионе, внимательно сверяйте конфигурацию, настройки региона должны совпадать.

Также подробный пример настройки MSTP на коммутаторах SNR у нас описан здесь в нашей базе знаний. Рекомендуем также ознакомиться.
 

Взаимодействие SNR с проприетарными PVST+/RPVST+

В ходе проведения тестов и исследований совместимости мультивендорных STP/RSTP/MSTP, которые используются на SNR, с проприетарными Cisco протоколами PVST+/RPVST+ было установлено, что корректная сходимость данных протоколов будет только в следующих сценариях:

1. PVST+/RPVST+ (Cisco) с STP/RSTP/MSTP (SNR), но корневым коммутатором должен быть именно SNR;
2. MST (Cisco) с STP/RSTP/MSTP (SNR).

Во всех остальных случаях возможны проблемы в работе: неправильный расчет костов, меняющиеся статусы портов и т.д.

Причина заключается в том, что Cisco отправляет два типа BPDU:

1. PVST BPDU на MAC-адрес 01:00:0C:CC:CC:CD. Кол-во отправляемых BPDU соответствует кол-ву VLAN на порту. Такие сообщения коммутаторы SNR пропускают прозрачно через себя, потому что не могут обработать их из-за проприетарности протокола;
2. В untagged VLAN (по умолчанию VLAN 1) также отправляется BPDU мультивендорного STP (если на Cisco настроен PVST) или RSTP (если на Cisco настроен RPVST) на MAC-адрес 01:80:C2:00:00:00. Отправляется данный BPDU в одном экземпляре. Это сообщение и должно в теории создавать совместимость между протоколами. Однако Cisco в своём Bridge ID (а если считает себя Root Bridge, то и в Root Bridge ID) использует Extended BID, т.е. добавляет значение VLAN в Extended System ID (как описано в стандарте 802.1t), и тогда поле priority в BID не будет кратным 4096. В этом случае SNR не может корректно обработать такой пакет, и STP начинает функционировать непредсказуемо.

В итоге, именно поэтому мы имеем “прыгающие” значения костов, или то, что Cisco в качестве корневого коммутатора периодически признает себя Root Bridge, но потом отказывается от этого, потом снова говорит, что он корневой, хотя блокирует свои порты и устанавливает cost невероятных размеров, и т.д.

Но это решает только одну проблему - прозрачную передачу PVST BPDU через SNR, но никак не поможет с обработкой пакетов, в которых используется Extended System ID.

Или можно попробовать изменить формат, отправляемых BPDU, но вероятнее всего, это не даст никакого результата.

Также все зависит от схемы. В какой-то схеме да, все может работать как часы, а в какой-то могут возникнуть вышеописанные проблемы, и сеть будет нестабильна.

Поэтому будьте внимательнее при настройке, планируйте свою сеть именно по принципам, описанным выше. Сценарии описанные выше - рабочие кейсы, все остальное - не рекомендуется.
 

Настройка spanning-tree на серии S5210

На данный момент по умолчанию на коммутаторах серии S5210 spanning-tree уже включен (в отличии от остальных линеек коммутаторов SNR). И включен по умолчанию режим RSTP, а не MSTP.

Поэтому если вам по какой-то причине не нужен spanning-tree на S5210, то его необходимо отключить глобально командой ‘spanning-tree shutdown’, либо исключить только какой-то конкретный порт из STP домена командой ‘spanning-tree disable’ в режиме конфигурации порта.

Можно заметить, что формат CLI на S5210 немного отличается от привычного нам Cisco-like CLI, но на самом деле это все тот же формат, просто с небольшими отличиями. Да и весь функционал работает аналогично.

Рассмотрим, какие команды здесь есть для настройки spanning-tree.

Большинство команд мы уже рассматривали на основной линейке коммутаторов SNR, но тем не менее еще раз пройдемся по всем командам, здесь могут быть некоторые отличия.

Команды spanning-tree из режима глобальной конфигурации

1. enable.

2. errdisable-timeout.

Данная команда является аналогом recovery на обычных коммутаторах SNR, когда порт переходит в состояние disable, например, после работы функционала bpduguard.

3. forward-time.

Настройки данного таймера и остальных аналогичны тем, которые мы рассматривали ранее. 

Установка значения таймера “Forward Delay Time” (задержка смены состояний).

Можно отменить установку таймера командой: ‘no spanning-tree forward-time’ - она вернет значение по умолчанию.

4. hello-time.

Настройка интервала отправки BPDU.

Можно отменить установку таймера командой: ‘no spanning-tree hello-time’ - она вернет значение по умолчанию.
 

5. instance.

В данном режиме мы можем настраивать bridge priority для разных instance на коммутаторе.

6. maxage.

Максимальное время жизни сообщения. Данный таймер показывает, когда текущий Hello BPDU устареет и должен быть удален.

Можно отменить установку таймера командой: ‘no spanning-tree max-age’ - она вернет значение по умолчанию.
 

7. max-hops.

Установка значения счетчика Max-Hop в MSTP, который определяет какое количество коммутаторов может пройти BPDU, до того как будет отброшен. Причем коммутатор должен работать именно в режиме MSTP, иначе коммутатор вернет ошибку, и команда не будет применена.

Можно отменить установку таймера командой: ‘no spanning-tree max-hops’ - она вернет значение по умолчанию.
 

8. mode.

Выбор режима работы spanning-tree.

9. mst.

10. portfast.

11. priority.

Если в команде ранее ‘instance X priority’ мы устанавливали bridge priority для различных MSTI, то в данном случае приоритет устанавливается для моста в контрольном instance, или IST (либо просто для моста в STP, RSTP).

12. shutdown.

Выключить процесс spanning-tree на коммутаторе глобально.

Отмена данной команды: ‘no spanning-tree shutdown’ будет эквивалентна команде ‘spanning-tree enable’, рассмотренной ранее.

13. transmit-holdcount. 

Как и ранее, эта команда устанавливает максимальное количество BPDU, отправляемых с коммутатора за один интервал Hello time.

Команды spanning-tree из режима конфигурации порта

1. bpdu-filter / bpdu-guard.

Мы можем принудительно вручную активировать функционал bpdu-filter или bpdu-guard на порту с помощью опции enable. Также можем принудительно отключить функционал для данного порта с помощью опции disable. А вот если выбрано значение по умолчанию - default, то будет активен функционал или нет, определяется командой из режима глобальной конфигурации, которую мы рассматривали ранее: ‘spanning-tree portfast’.

2. disable / enable.

Тут все просто - отключение / включение spanning-tree на порту.

3. guard.

Включение защиты root guard на порту (чтобы при получении superior BPDU, порт не становился корневым).

4. hello-time.

Установка значения интервала hello-time для BPDU, отправляемых с какого-то конкретного порта.

5. instance.

6. link-type.

Выбор типа линка.

Auto - коммутатор будет определять тип линка автоматически, исходя из настроек дуплекса на порту;

Point-to-point - будет принудительно выбран p2p тип линка;

7. path-cost.

8. portfast.

Принудительно обозначить порт как “edge-порт”, т.е. порт, который будет сразу же переходить в состояние Forwarding.

9. restricted-role.

Запретить порту становиться root портом.

Казалось бы, в чем тогда отличие от команды ‘spanning-tree guard root’? А отличие в механизмах реализации.

В функционале “root guard” при получении на порт лучшего BPDU, чем текущий корневой коммутатор, порт переходит в состояние root-inconsistent (эквивалентно состоянию Listening).

По умолчанию функционал отключен.

10. restricted-tcn.

Функционал похож на тот, который мы рассматривали на обычных коммутаторах SNR (tcguard, tcn-guard). Однако там происходило отбрасывание таких BPDU, а здесь же, при поступлении BPDU в нем будут проигнорированы флаги об изменении топологии, и BPDU будет обработан без них (не будет отброшен).

Заключение

Итак, в данной статье у нас получилось рассмотреть подробно каждый протокол из семейства spanning-tree. Понятно, что, в любом случае, не удастся учесть все детали и нюансы, но мы постарались это сделать.

Также мы рассмотрели нюансы настройки и работы spanning-tree на коммутаторах SNR.

В качестве заключения предлагаю рассмотреть такие тезисы:

• Почему НЕ spanning-tree (а, условно, какой-нибудь ERPS)?
• Почему spanning-tree?

1. Почему НЕ spanning-tree (а, условно, какой-нибудь ERPS).

• Время сходимости: тот же ERPS сходится гораздо быстрее практически во всех случаях (однако в случае восстановления канала, быстрее может все-таки оказаться RSTP).
• Spanning-tree расходует больше ресурсов CPU коммутатора, чем ERPS;
• В ERPS есть наличие таймера "hold-off", который исключает полную неработоспособность сети в случае частого изменения состояния порта, чего нельзя сказать про семейство spanning-tree. 

2. Почему spanning-tree.

• Протоколы STP достаточно распространенные: используются практически на любом современном вендоре, при каких-либо проблемах/вопросах, всегда можно быстро найти информацию по работе spanning-tree в сети интернет: обучающие видео, курсы, статьи, форумы и т.д.;
• Поскольку spanning-tree очень распространен, он весьма прост в настройке и в понимании логики его работы;
• Может применяться на любой топологии, необязательно даже в кольцевой.

Как видите, есть свои плюсы и минусы. Поэтому какой именно протокол использовать - все зависит от потребностей и особенностей сети.

Напоследок еще рассмотрим возможные проблемы в работе STP и best practice:

1. Для включения spanning-tree на порту spanning-tree должен быть включен глобально;
2. Не всегда стоит полагаться на автоматику, лучше управлять своей сетью самому: Bridge Priority, path cost и port priority лучше настраивать вручную;
3. Параметры spanning-tree взаимосвязаны и необходимо соблюдать следующие соответствия, иначе spanning-tree может работать некорректно: 
   2 x (Bridge_Forward_Delay - 1 sec) >= Bridge_Max_Age
   Bridge_Max_Age >= 2 x (Bridge_Hello_Time + 1 sec)
4. Если по какой-то причине не работает алгоритм rapid spanning-tree - proposal/agreement, а сам протокол работает по классическим таймерам STP, то необходимо проверять типы подключенных линков (p2p или shared), какой протокол spanning-tree работает на соседе (может быть, на соседе запущен STP);
5. Лучше использовать RSTP, если нет необходимости осуществлять балансировку в множестве VLAN, или соответственно MSTP для этой цели. Классический STP в современных сетях использовать не рекомендуется;
6. Если используется spanning-tree на коммутаторах SNR вместе с PVST, то необходимо, чтобы корневым коммутатором был коммутатор SNR. В противном случае, рекомендуется использовать MST, а не PVST;
7. Предпочтительнее, чтобы в сети при использовании MSTP существовал только один регион. Это упрощает конфигурацию, управление и уменьшает вероятность возникновения ошибок;
8. Если коммутаторы оказываются в разных регионах, то необходимо проверить на них консистентность настроек: имя региона, маппинг vlan-instance, номер ревизии. Если все одинаково, то необходимо смотреть какое значение MD5-хеша отправляют коммутаторы, и при необходимости использовать digest-snooping;
9. При диагностике всегда можно запустить сбор дебага spanning-tree и, при необходимости, выбрать какую-либо опцию: 
    

(не забыть прописать ‘terminal monitor’, чтобы сообщения дебага появились в терминале).

И нужно всегда помнить, что изменение параметров spanning-tree может вызвать изменение топологии.

«Цифровые привычки» пользователей формируют новые бизнесы, стимулируют рост сетевых соединений и высоконагруженных сервисов. Связность, скорость обмена трафиком и время отклика сети становятся главными конкурентными преимуществами. Переход к цифровой эпохе требует надежной инфраструктуры, которая позволит не только хранить постоянно увеличивающийся объем данных, но и поддерживать их доступность для пользователей. Ключевую роль в решении этой задачи играют высоко связные (коннективные) кампусные структуры дата-центров и экосистемы сервисов, которые возникают вокруг них. 

Как дата-центру обеспечить максимально высокий уровень связности для своих клиентов?

В первую очередь, быть нейтральным, то есть, не связанным эксклюзивными отношениями с каким-либо поставщиком услуг связи. «Моногамность» не идет ЦОД на пользу. Чем шире экосистема дата-центра, чем больше у него партнеров − операторов связи, провайдеров облачных услуг, CDN и пиринговых платформ, тем больше сетевых возможностей он может предоставить своим клиентам. Нейтральность позволяет пользователям услуг ЦОД самостоятельно выбирать партнеров для создания цифровых проектов и гибридных ИТ-инфраструктур и открывает компаниям из любой сферы − финтеха, гейминга, онлайн-дистрибуции и т.д. − неограниченные возможности для роста.

Чтобы обеспечить связность с любым участником сетевого обмена, дата-центр должен функционировать как полноценный инфраструктурный хаб. Архитектура такого хаба предполагает наличие множества сетевых элементов, необходимых для быстрой транспортировки информационных потоков. Это и специальные машинные залы, и прямые подключения к платформам обмена трафика, и кросс-коннекты для подключения оборудования как по меди, так и по ВОЛС, а также независимые маршруты кабельных вводов к кабельной инфраструктуре города. Архиважную роль для связности играют альтернативные (резервные) каналы и точки их пересечения, в которых возможна коммутация трафика. Они позволяют перераспределять нагрузку на сеть и сохранять ее работоспособности при отказе одного из каналов.

Не следует также забывать о внутренней коннективности ЦОД.  На смену одиночным объектам все чаще приходят кампусы, объединяющие сразу несколько территориально разнесенных дата-центров под управлением одного провайдера. Показателем высокой связности в данном случае является наличие стабильных и надежных линий оптоволоконной связи между всеми кампусами и объектами внутри них. При этом сервис-провайдеры, доступные на одной из площадок, должны быть доступными для клиентов на всех других площадках. Так, например, всем клиентам Южного кампуса IXcellerate доступны как прямые подключения к узлам связи, размещенным в дата-центре MOS5, так и возможность соединения с любым из присутствующих операторов связи на Севере благодаря оптической магистрали между кампусами. Подключаясь напрямую к точкам присутствия операторов, клиенты значительно выигрывают в скорости передачи данных.

ЦОД – современный маркетплейс онлайн-сервисов

В последние годы мы наблюдаем четкий тренд: из хранителей информации дата-центры превращаются в маркетплейсы интернет-услуг, платформы для развития цифровых продуктов клиентов. Возникает синергия, которая обеспечивает высокую степень масштабируемости и резервируемости инфраструктуры, непрерывность бизнес-процессов и возможность реализации проектов любой степени сложности. В выигрыше оказываются все участники процесса – и дата−центры, и их заказчики, и партнеры. Быстро растущий ЦОД, который постоянно вводит новые мощности, открывает своим партнерам доступ к новым клиентам. Более того, он может также предоставить им возможность предлагать услуги colocation на собственных площадках. Благодаря этой возможности корпоративные заказчики телеком-оператора могут получать не только услуги связи, но и планировать комплексные проекты цифровизации, размещать и масштабировать свою инфраструктуру.

Чем больше новых услуг, чем масштабнее проекты, чем выше удовлетворенность конечных пользователей, тем быстрее растет объем цифровых данных. А значит, тем больше сетевой инфраструктуры требуется для их хранения и передачи. Цикл начинается снова. Вот такой цифровой Уроборос. 

Об авторе

Олег Огиенко – эксперт в области телекоммуникаций и Интернет-сервисов, имеет более чем 10-летний опыт в области продаж и управления проектами в сфере передачи данных. В 2021 году присоединился к команде IXcellerate в качестве Руководителя пиринговой платформы Eurasia Peering. Имеет степень магистра, выпускник МАИ и РАНХиГС.

Кажется, провайдеры и операторы связи стали забывать про требования законодательства.

Впервые про термин КИИ в России услышали с выходом Федерального закона № 187 ФЗ, который создал правовую базу для присвоения информационным системам, информационно-телекоммуникационным системам, автоматизированным системам управления - «критического» статуса.

Это значило лишь то, что любая компания, работающая в стратегических сферах экономики, будь это наука, здравоохранение, транспорт, энергетика, банковская сфера, связь, топливно-энергетический комплекс, в области атомной энергии, оборонной, ракетно-космической, горнодобывающей, металлургической и химической промышленности, а также организации, которые налаживают и обеспечивают взаимодействие информационных систем или сетей для перечисленных структур – становятся субъектами критической информационной инфраструктуры.

На различных производствах построены сети, в которых есть автоматизированные системы управления (или же, АСУ) – такие информационные системы, в рамках закона, и называются объектами критической информационной инфраструктуры, которая непременно должна защищаться различными средствами защиты информации, иначе, в случае компьютерного инцидента, который, впоследствии выведет такие системы из строя, могут быть человеческие жертвы и серьезный урон экологии.

Проблематика

Итак, мы с вами разобрались, что такое КИИ и кого мы можем называть субъектом критической информационной инфраструктурой. Но что насчет ответственности и требований по информационной безопасности?

В начале я оставил слова про провайдеров, потому что в информационном мире бывают своеобразные поставщики услуг, и по схеме взаимодействия объектов КИИ они становятся посредником, который тоже становится КИИ, но с условием. Звучит это, немного странно, но по правилам, предусмотренным законом N 187- ФЗ, отнесение любого ИП, российского юридического лица, государственного учреждения и государственного органа к субъектам КИИ осуществляется по:

• Виду деятельности или сфере деятельности (8 пункт, статьи 2).
• ОКВЭД относится к одному из перечисленных выше секторов экономики.
• Праву собственности, аренды или на ином законном основании любые ИС, ИТКС и АСУ.
• Факту обеспечения взаимодействия ИС, ИТКС и АСУ, принадлежащих государственному органу, государственному учреждению, российскому юридическому лицу и/или ИП, осуществляющих свою деятельность в одной или нескольких сферах деятельности, предусмотренных пунктом 8, статьи 2.

Имея в наличии даже один из этих критериев субъекта КИИ, предоставляя услуги по виду деятельности или сфере деятельности, указанных в ФЗ 187, провайдер сразу становится субъектом КИИ, а его инфраструктура – объектом КИИ.

Существуют категории КИИ, которые делятся, непосредственно, на три категории:

• (III) Третья – младшая категория.
• (II) Вторая – средняя категория.
• (I) Первая – самая высокая.

Несмотря на наличие каких-либо объектов КИИ, эти объекты не всегда бывают значимыми. Для любого оператора связи «критическим» приговором может стать предоставление своих услуг определенному числу абонентов – от 3000 человек. От этого числа провайдер получает свою категорию значимости – третью, согласно таблице с критериями в ПП РФ №127

Даже если провайдер не имеет значимых объектов критической информационной инфраструктуры, он обязан провести инвентаризацию следующих систем:

• Информационных.
• Программных.
• Технических.

Параллельно, необходимо выявить те самые критические события: сбои, остановка работы каналов связи, которые приведут к негативным социальным, политическим и экономическим последствиям.

Операторам связи, оказывающим услуги для государственных органов власти, необходимо рассмотреть негативные последствия в виде возникновения ущерба бюджетам РФ (федерального, субъекта РФ, внебюджетных фондов) и нарушение или прекращение функционирования органа власти в возложенного на его функции.

А что с информационной безопасностью?

Операторы связи живут в своей сфере, принимая трафик по брасам, иногда перебирают агрегацию сети.

Информационная безопасность тоже требует внимания. В любой организации должны быть свои SOC (Security Operation Center), хотя бы один человек, который будет согласно политикам и/или регламентам следить за порядком в сети и искать отклонения в миллионе логов, аккуратно сосредоточенных в предназначенных для этого системах.

В информационно-правильной системе должен быть «бумажный» специалист по безопасности, который следит за всеми регламентами, следит и отвечает за порядком их исполнения. Как правило, этот ИБ-шник не сидит перед экраном в интерфейсе EDR, SIEM, NTA-системами и не знает как с ними работать. Его задача – грамотно написать «программу» по планированию, проектированию, подбору, внедрению и сопровождению перечисленных ранее систем.

И есть тот самый офицер информационной безопасности, который знает как работает вся инфраструктура и через сколько фильтров проходит трафик, прежде чем выйти в глобальную сеть и наоборот. В каких-то организациях этот человек один – он занимается мониторингом и устранением уязвимости или инцидентами безопасности. Но, по феншую офицер безопасности как система SOAR – он тот самый начальник, который дает рядовым инженерам по обязанности, и, так он налаживает процессы в одной глобальной задаче – обеспечивать информационную безопасность в компании.

Но что, если на данный момент оператор связи имеет свою привычную инфраструктуру из коммутаторов и маршрутизаторов, которые обеспечивают работу всего бизнеса, и, казалось бы, всё просто замечательно, а тут распределенная атака на отказ оборудования, брут внутренних административных ресурсов с клиентских ПК, сайт повис насмерть... ? Для компании перечисленные события как нечто противное и неприятное, когда кто-то другой копается в сети или пытается её уронить, но, в случае, если сеть оператора связи упадет – это потеря доходов и множество недовольных клиентов, которые в любой момент могут разорвать договор и уйти к конкуренту.

С чего начать?

Скажем так, любой провайдер старается соблюдать законодательство, чтобы его не душили штрафами, взысканиями и проверками, а это – РКН, СОРМ, Яровая. 

Теперь, каждый провайдер должен защищаться, и не просто от взысканий, а от угрозы безопасности, которая может реализоваться в любой момент. Это больше не "русская рулетка" с "пулями", а требование законодательства, потому что многие провайдеры являются связующими точками в большой информационной инфраструктуре Российской Федерации.  

После проведенных мероприятий инвентаризации сети, уведомления в органы власти, разработки плана X – нужно действовать. Миллионы ACL на коммутаторах могут сделать супер-правильный строй трафика и защитить от «дурака», но не защитит от реальных атак. Поэтому, для начала, необходимо задуматься об шлюзе безопасности. Сейчас это называется NGFW - Next Generation FireWall, потому что это целый кухонный комбайн в сфере информационной безопасности, в нем есть защита от DDoS, правила межсетевого экрана, система обнаружений вторжений, потоковый антивирус, VPN, SSL-инспекция трафика, фильтрация контента и прочее.

Межсетевой экран должен стать стеной между глобальной сетью и корпоративными сегментами, чтобы весь сетевой трафик инспектировался и из него исключались несанкционированные действия на базе сигнатур известных атак, а также, чтобы обнаружить нарушения политики безопасности и фильтровать спам как снаружи, так и внутри.

Это очень важно для любой компании, межсетевые экраны должны стоять в любой инфраструктуре, а для провайдеров это особенная тема: когда каждый день кого-то атакуют, и эти атаки не заканчиваются одними DDoS’ами.

У каждой организации есть своё веб-лицо – сайт, на котором есть информация об деятельности компании, возможно есть авторизация и даже платежные механизмы. Всё это тоже требует наблюдения и постоянной защиты от злоумышленников, потому что, банально, есть атака до отказа на L7-уровне, который положит сайт и может серьезно нагрузить сервер.

Это решение класса Web Application Firewall – такой межсетевой экран работает на прикладном уровне и предназначен для защиты от атак HTTP-запросами к серверу, которые могут скрывать в себе серьезную угрозу, впоследствии открывающую дыру в защите инфраструктуры компании. Можно потратить время и привести в порядок все конфигурации сервера и сайта, защитив от 10-15% атак, но этого недостаточно - в подавляющем большинстве веб-ресурсов есть уязвимости, и, при необходимости, злоумышленник будет перебирать все способы. В конце концов, сервер сам себя не защитит от атак на логику ресурса, перебивания буфера бесконечным количеством HTTP-запросов.

Внутри инфраструктуры можно и нужно устранять лишний доступ, составлять политики доступа для группы лиц и не допускать неавторизованный доступ до каких-либо ресурсов или сегментов сети. От подобных угроз защищают различные NAC-продукты, завязанные на технологии Endpoint Security – это не защита эндпоинтов от конкретных атак, это защита «друг от друга». Кто-то пользовался Cisco ISE, но в текущих реалиях, пришло время импортозамещаться.

Также, помимо NAC, есть узконаправленные решения типа Access Manager, которые не дают пользователю доступ до корпоративной сети и выход в глобальную сеть, пока не будет выполнена двухэтапная аутентификация, и пользователь не будет авторизован.

Когда в сети уже очень много оборудования, отовсюду плывет много трафика, и при этом, необходимо отслеживать подозрительные активности – требуется концентрация логов в SIEM (Security Information and Event Management). Решение этого типа собирает в себя события из различных источников, которые можно интегрировать, например – IDS, DLP, APM, маршрутизаторы.
 

Все события с устройств создают накопленную статистику. Тем самым, SIEM может сгенерировать событие безопасности, если произошло что-то, выходящее за рамки привычных сценариев. Например, сотрудником с соответствующими правами отправляется чувствительная информация по адресу, который не должен получать эту информацию. Также, производители поставляют свою экспертизу с различными вариантами инцидентов.

Говоря об инцидентах, бывают совсем неочевидные события, которые вручную расследовать крайне сложно и долго. Для обнаружения факта события безопасности в ретроспективе, либо происходящего вторжения, придумано решения класса NTA (Network Traffic Analysis). NTA помогает найти в копии L2-L7 трафика следы атаки, работая с зашифрованным трафиком. Также, находит признаки нарушения регламентов ИБ (нелегальные протоколы, отправка информации в открытом виде), выявляет модифицированные ВПО.

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

Итоги

Операторы связи должны обратить внимание на важность проблемы. Информационная безопасность – это безопасность вас самих. В любой организации должен быть офицер ИБ, который поддерживает соблюдение регламентов и тот, кто поддерживает работу СЗИ в инфраструктуре. Первым шагом в обеспечении безопасности является наведение порядка в информационном взаимодействии во внутренней и внешней сети и установка базовых средств защиты информации. 

От этого не сбежишь, когда условия диктует государство. 

В этом материале мы хотим познакомить наших читателей с новинками в линейке коммутаторов SNR.

В 2022-2023 годах модельный ряд коммутаторов SNR увеличился на целых 8 моделей. Линейки пополнились новыми моделями коммутаторов уровня доступа, а также агрегации/ядра.

Во-первых, уже появились в наличии и доступны для заказа новинки производительного L3-доступа в серии S3850G, такие как SNR-S3850G-24TX и SNR-S3850G-48TX. Их ключевое новшество - это наличие двух встроенных блоков питания 220V AC, что позволяет эффективно резервировать оборудование при отключении электропитания.

SNR-S3850G-24/48TX

Во-вторых, для уровня агрегации/ядра появились новые высокопроизводительные модели SNR-S7550Y-48C и SNR-S7550C-32F. В них, прежде всего, отметим поддержку таких протоколов как MPLS, EVPN+VXLAN, а также, впервые в линейке, 100-гигабитные QSFP28-порты. В дополнение ко всему этому, выделим поддержку протокола MLAG, который можно использовать как более эффективную альтернативу стекированию.

Кроме того, на уровень доступа в ближайшее время (конец 2023 г.) появятся на складе новые модели серии S2989G, а именно: SNR-S2989G-8TX, SNR-S2989G-8TX-POE, SNR-S2989G-24TX-POE и SNR-S2989G-48TX-POE.

SNR-S2989G-48TX-POE

Рассмотрим новинки 2023 года по части программного обеспечения и технических характеристик. Во всех новых моделях используется стандартный для  коммутаторов SNR Cisco-like CLI и MIB, то есть интеграция в сеть не составит проблем, а ветка ПО будет идентична для серий S2989 и S3850. Для коммутаторов серии SNR-S7550 будет своя отдельная ветка ПО, но практически идентичная модели SNR-S4650X-48FQ.

Теперь обратим внимание на технические характеристики и начнем обзор с новинок в серии S2989G. Новые коммутаторы уровня доступа построены на пакетных процессорах компании Marvell, а также на основе софта серии S2995G, который уже отлажен и доработан под требования наших постоянных клиентов. Поэтому для тех, кто уже знаком с коммутаторами SNR, и с серией S2995G в частности, интеграция в сеть новой модели не составит проблем. Рассмотрим ниже основные характеристики этих моделей:

Портовая емкость новинок  является стандартом для построения "честного" гигабитного доступа, при  котором полоса пропускания Uplink-порта не может быть полностью занята  одним пользователем с гигабитным тарифом. Это 8/24/48 медных порта Gigabit  Ethernet и 4 SFP+ Uplink-порта. Одной из ключевых особенностей выделим 4 SFP+ порта для 8-портовых моделей, хотя, по классике, для такой портовой емкости обычно присутствует только два порта. Для удобства управления модель оснащена выделенными management и  консольными портами, а также USB-портом для подключения внешних  накопителей.

Важно отметить, что, в отличие от старших моделей коммутаторов SNR,  построенных на чипсетах Marvell, серия S2989G является L2-серией уровня доступа, L3-функционал у нее отсутствует. Однако, эта серия поддерживает статическую маршрутизацию, что добавляет некую уникальность и позволяет использовать её в разных сценариях при построении сети.

Теперь рассмотрим другие новинки, уже в серии S3850G. Как мы уже писали выше, она пополнилась двумя новыми моделями с медными портами 10/100/1000Base-T и 1/10GE SFP+ Uplink. Взглянем на их основные характеристики:

Самая главная их отличительная особенность и преимущество - это наличие двух встроенных блоков питания, что позволяет резервировать электропитание устройства без каких-либо дополнительных доработок и повышает отказоустойчивость вашей сети. Более подробно данную тему рассмотрели в нашем вебинаре по резервированию электропитания на коммутаторах SNR.

В остальном, по внешнему виду и ПО, коммутаторы идентичны серии S2995G. С точки зрения функционала, коммутаторы серий S2995G и  S3850G также одинаковы. Отличие лишь в  большем размере L3-таблиц и повышенной производительности у серии S3850G:

Наконец, мы дошли до наиболее интересных и уникальных наших новинок - коммутаторы SNR-S7550Y-48C и SNR-S7550C-32F. Это самые высокопроизводительные коммутаторы в линейке SNR, предназначенные для применения на уровне агрегации и ядра сети или в ЦОД. Модели построены на современном чипсете одного из лидеров отрасли -  Broadcom, который обеспечивает минимальные задержки при передаче пакетов и имеет поддержку MPLS, VXLAN, MLAG. В таблице ниже приведены основные характеристики устройств:

Первое, на что сразу хочется обратить внимание – это уникальная портовая емкость. Коммутатор SNR-S7550Y-48C оснащен 48x SFP28-портами, которые могут работать на скорости 25 Гбит/с и 6x QSFP28 портами, пропускная способность которых 100 Гбит/с, а модель SNR-S7550C-32F оснащена 32х QSFP28 портами. Присутствуют два слота для установки модульных блоков питания, резервируемых по схеме 1+1 с возможностью замены в процессе работы коммутатора (блоки питания AC в комплекте). Система охлаждения коммутатора - front-to-back, т.е от передней панели к задней.

Коммутаторы поддерживают как static unicast VXLAN, так и EVPN-VXLAN, что позволяет использовать его при построении сетей ЦОД. Данная модель может успешно выполнять роль TOR или Leaf-коммутатора. К тому же, наличие протокола VXLAN обеспечивает простоту интеграции сетевого оборудования в существующую сеть ЦОД, а также повышает масштабируемость и надежность вашей сети.

Данные модели, так же как и многие другие коммутаторы SNR, поддерживают протокол VSF, который  позволяет объединить 4 физических коммутатора в одно логическое устройство, тем самым упрощая конфигурирование и повышая надежность сети. Стекирование производится через стандартные порты и не требует дополнительных плат. Но мы не ограничились только стекированием. Впервые в линейке коммутационного оборудования SNR, данные модели поддерживают функционал MLAG. Это технология объединения data plane нескольких коммутаторов в один логический data plane, но с сохранением раздельного control plane на  каждом из коммутаторов. Данная технология имеет ряд преимуществ по сравнению с обычным  стекированием через VSF:

• Не используется общий control plane как при VSF.
• В случае падения master-коммутатора, стек не развалится, а просто делегирует функции на другой  коммутатор.
• В MLAG-стеке каждое устройство самостоятельно, можно обновлять их ПО отдельно.

В дополнение ко всему, модели SNR-S7550Y-48C и SNR-S7550C-32F  поддерживают MPLS, включая L3 VPN и L2 VPN (VPLS, VPWS), что позволяет строить защищенные и функциональные сети, а большое пространство меток позволяет использовать коммутаторы в качестве PE или P-маршрутизатора.

Для примера настроим простую схему EVPN+VXLAN с оборудованием другого вендора и коммутатора SNR-S7550Y-48C:

Как можно заметить, данный функционал коммутатора настраивается довольно просто и отлично работает в связке с другими вендорами. Поэтому вы можете смело использовать данные коммутаторы для построения или интеграции в сети ЦОД.

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

В заключении хотелось бы сказать, что мы:

Всегда прислушиваемся к вашим пожеланиям и запросам, поэтому у всех новинок добавили совершенно новые возможности, которых, ранее, никогда не было в коммутаторах SNR. Это и 4 SFP+ Uplink-порта для 8-ми портовых моделей и два встроенных блока питания для коммутаторов S3850G и, конечно же, поддержка MLAG + EVPN VxLAN для серии S7550.

Продолжаем активно развиваться. Например, помимо данных линеек мы постепенно расширяем серию коммутаторов российского производства S5210, в которой уже вышла на рынок модель SNR-S5210X-8F с уникальной портовой емкостью и эргономичным дизайном — 8x10GE SFP+, причем это не единственная модель с оптическими портами в серии! В начале третьего квартала 2023 года мы вывели на рынок SNR-S5210G-24FX,  данная модель работает под управлением общего для всей серии ПО и отличается наличием 20 портов 100/1000Base-X SFP, 4 Combo порта GE и 4 порта 1/10G SFP+. А в ближайших планах выход модели с PoE - SNR-S5210G-24TX-POE, а также её ТОРП-версия! Прислушиваясь к запросам клиентов, мы запланировали выход моделей на 48 портов (в том числе с PoE) и да, там будет 6 портов 1/10G SFP+. Кстати, посмотрите нашу новую презентацию там не только сосредоточена ключевая информация по этой линейке, но и актуальная дорожная карта.

А поэтому, оставайтесь с нами и следите за новостями в нашем telegram-канале SNR-SWITCH-NEWS!

В этой статье мы готовы поделиться с вами опытом реализации подобных проектов. Ключевыми этапами являются радиопланирование и радиообследование.

Радиопланирование от НАГ — комплекс мероприятий, направленный на моделирование работы Wi-Fi-сети для определения её оптимальной конфигурации на объекте заказчика. Моделирование производится с помощью специализированного программного обеспечения.

Радиопланирование решает следующие задачи:

• Создания дизайна новой сети Wi-Fi.
• Составления спецификации на основе дизайна сети Wi-Fi.
• Визуализации ключевых параметров Wi-Fi в виде итогового отчета.

Радиообследование от НАГ — комплекс мероприятий, включающий в себя изыскание, инспектирование и технический консалтинг для последующей оптимизации Wi-Fi-сети на объекте заказчика, выезд на объект с использованием портативного спектроанализатора.

Радиообследование решает задачи:

• Поиска неисправностей (troubleshooting) и оптимизации существующей сети Wi-Fi.
• Оценки результата радиопланирования на объекте заказчика.

Основные этапы радиопланирования и радообследования:

• Определение требований — собираем все необходимые вводные, составляем и согласовываем ТЗ.
• Проектирование — радиопланирование, т.е. создание виртуальной модели Wi-Fi сети на основе ТЗ.
• Внедрение — заказ оборудования, поставка, шефмонтаж, сопровождение.
• Проверка — пассивные и активные радиообследования, сравнение полученного с требованиями, согласно ТЗ.
• Сдача проекта заказчику — наслаждаемся работой правильного Wi-Fi.

Работая вместе с НАГ вы получаете доступ к  специализированным инструментам для проведения радиопланирования и радиообследования и компетенциям ведущих специалистов. Это гарантирует качество оказываемых услуг и экономию ваших человеческих и денежных ресурсов.

Ознакомиться с компетенциями НАГ и реализованными проектами вы можете по ссылке. Далее, более подробно поделимся с вами одним из проектов на примере логистического склада.

Проект был нацелен на разработку дизайн-схемы размещения точек доступа Wi-Fi и последующего их обследования на складе хранения одного из крупнейших ритейлеров. Отправной точкой этого проекта был простой вопрос от заказчика: «как разместить точки доступа на новом, еще пока строящемся, складе так, чтобы мы не испытывали проблем при целевом использовании Wi-Fi для терминалов сбора данных?». Также, на первых этапах заказчиком уже был выбран вендор Wi-Fi-оборудования. И, как уже говорилось ранее, наша основная задача заключалась в правильной компоновке Wi-Fi-сети.

Сотрудниками НАГ, совместно с представителями заказчика, при помощи специализированных инструментов была разработана дизайн-схема размещения точек доступа Wi-Fi. При её составлении учитывались:

• Особенности склада (расположение стеллажей, процент наполненности стеллажей, что за продукция будет храниться на этих стеллажах и др.).
• Технические характеристики точек доступа (высота подвеса точек доступа,  коэффициент усиления, диаграмма направленности и др.).

По окончании строительства склада, представители заказчика развернули Wi-Fi-сеть, основываясь на предоставленной ранее дизайн-схеме по размещению точек доступа. После основной настройки этой Wi-Fi-сети сотрудники НАГ отправились на логистический склад заказчика, чтобы провести радиообследование. Основной задачей было проверить работоспособность сети, выявить несоответствия ТЗ и дать рекомендации по их устранению.

Используя специализированные инструменты, специалисты НАГ выявили небольшие несоответствия ТЗ, связанные с настройками сети Wi-Fi на контролере.

Быстро устранив данные несоответствия путём регулирования мощности, поканального распределения точек доступа и уменьшения ширины канала до 20 МГц в 5 ГГц,  мы получили покрытие Wi-Fi максимально близкое к ТЗ, которое было изначально заложено в данную систему. Вся проделанная работа, а точнее начальные, промежуточные и финальные результаты были подробно отражены в отчете (примеры по расположению точек доступа и карты покрытия взяты именно из него).

После применения финальных настроек на контроллере Wi-Fi точек доступа, наступил финальный этап реализации проекта – эксплуатация сети. В результате которого с нами поделились положительными отзывами:

На примере, показанном выше, удалось показать основные этапы реализации проекта по направлению Enterprise Wi-Fi. В ходе выполнения ключевых этапов радиопланирования и радиообследования у команды НАГ было четкое понимание по необходимой спецификации оборудования и ключевым параметрам Wi-Fi на данном объекте, что гарантировало успешное выполнение поставленной задачи в рамках данного проекта.

Вместе с НАГ вы можете реализовать любой амбициозный проект!

Отечественная телекоммуникационная отрасль никогда не считалась тихой гаванью. Каждый год, начиная с КРОС-2006, операторы искали друг у друга поддержки в борьбе с таким количеством невзгод, что всякий раз было понятно: на следующую конференцию либо не приедет никто, потому что будет просто некому, либо приедут самые сильные, самые лучшие - выжившие. 

Минувший год старательно поддерживал все условия для сохранения этой традиции: проблемы у специалистов важнейшей отрасли страны продолжают расти, как снежный ком. Тем отраднее было видеть в холле сочинского Radisson Blu Resort & Congress Centre как сотни знакомых лиц, так и новичков, приехавших на крупнейший отечественный форум, впервые. Более 800 человек на три дня превратили популярный отель в мозговой центр российского интернета, плотность интеллекта на единицу площади в котором, просто зашкаливала. 

На самом деле, участники начали прибывать в отель еще загодя: кто за день, кто - за два, а кто и за три. Но основная масса людей начала подъезжать в середине дня 17 мая. 

День заезда на конференции выполняет роль буфера между привычной размеренной жизнью и напряжённым графиком работы в совершенно другом ритме, когда нужно не только выбрать самое интересное в плотном потоке докладов, но и успеть познакомиться и пообщаться с десятками незнакомых коллег, осмотреть шоурум, принять участие в круглых столах и переговорах. Поэтому первый день - это всегда активный спортивный отдых и расслабляющая вечеринка.

Спорт

Если футбол и волейбол прописались на КРОС достаточно давно, то парусную регату мы проводили впервые. Площадка отеля вплотную прилегает к небольшому порту и не воспользоваться такой возможностью мы просто не могли. Поэтому в середине дня порядка 130 участников, принявших участие в спортивных мероприятиях, не только пинали футбольный мяч и подбрасывали в небо мяч волейбольный, но и облачившись в спасательные жилеты, вышли на яхтах в море.

BBQ-вечеринка 

На вечеринке первого дня у бассейна мы впервые поставили два больших экрана, которые позволили видеть всё, что происходит на сцене из любого уголка площадки. А на сцене происходило немало интересного. Помимо выступления танцевальной группы, там награждали участников спортивных турниров, проводился гитарный вечер, на котором выступали сотрудники "НАГ", а гвоздём программы стало выступление легендарной группы "7Б". 

Дополняли прекрасный майский вечер многочисленные миниатракционы, караоке и дискотека.

Партнёры КРОС-2023

Партнёры конференции помогают провести мероприятие на более высоком и качественном уровне. 

Шоурум

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

Деловая часть

В этом году у нас работало три зала достаточной большой вместимости, чтобы исключить ситуации с нехваткой мест на каком-либо докладе. Жесткой привязки какой-либо секции к определенному залу делать не стали, хотя и постарались выстроить деловую часть так, чтобы близкие по направлению доклады не требовали постоянного перебегания из зала в зал. В зале "Премьер" велась видеозапись докладов. 

Все видеозаписи деловой части доступны в плейлисте YouTube.  
Все презентации одним пакетом можно скачать здесь.

Отвечая на вопрос о лучших спикерах конференции, участники  анкетирования назвали следующие имена: 

• Алексей Семенцов.
• Роман Тарасенко.
• Тимур Чудутов.

Наибольшую аудиторию, согласно данным анкетирования, собрал Искандар Бахтияров (Уфанет).

Гала-ужин 

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

У нас получился банкетный зал общей площадью порядка 1500 кв. метров, со сценой и 4 экранами, на которых демонстрировались фотографии, видеоролики и живая трансляция того, что происходило возле сцены. Круглые банкетные столы с изысканной сервировкой и снующими официантами окончательно превратили три помещения для деловой части в  один яркий банкетный зал. Ну а дальше - все как обычно. Элегантные мужчины, прекрасные дамы, шум и веселье, шоу, музыка и несколько прекрасных часов для общения и восстановления сил перед следующим рабочим днём конференции. 

Материалы для скачивания

• Все фотографии КРОС-2023.
• Все презентации деловой части в одном архиве.
• Все видеозаписи докладов.
   

Вместо эпилога

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

Без сомнений, очередной КРОС удался на славу. В анкетах участники мероприятия отмечали, что вырос уровень деловой части, а смена площадки нисколько не ухудшила организацию конференции, в целом, хоть и добавила хлопот организаторам. Неоднократно приходилось также слышать, что достигнут "потолок" и ничего, по большому счёту, улучшить уже нельзя. 

Уважаемые участники, проводить каждый следующий КРОС лучше, чем предыдущий, ежегодно поднимать планку качества и уровень требований к себе, давно стало точно такой же доброй традицией для организаторов, как и общее фото участников. Мы уже собираем и суммируем отзывы, анализируем ошибки и потенциал свежих находок. КРОС-2024 будет лучше, чем все, что мы проводили ранее - даже не сомневайтесь. :-)

До встречи на КРОС-2024!

В последние годы международная обстановка влияет на телекоммуникационный рынок России, пожалуй, как никогда ранее. Одни производители покинули российский рынок совсем, другие были вынуждены менять логистику, а третьи и вовсе оказались перед необходимостью создавать новые модели оборудования, поскольку в силу непредсказуемых событий и решений, оказались отрезаны от поставок некоторых комплектующих.

Все это в совокупности неизбежно меняет привычную структуру телекоммуникационного рынка, и, хотя операторы не остались без оборудования совсем, многие устоявшиеся схемы приходится теперь перерабатывать, а привычные взгляды — пересматривать.

В этой статье мы попробуем разобраться, что же изменилось для обычного российского оператора, вынужденного решать вопросы по замене оборудования для имеющихся и перспективных PON-сетей. Я назвал статью «Выжившие», так как, несмотря ни на что, описываемые продукты либо продолжают оставаться доступными к заказу, либо имеются в наличии на складе. То есть, это готовый список проверенных вариантов, из которых осталось лишь выбрать то, что вам в текущий момент подходит больше всего.

Вообще говоря, все доступное оборудование можно условно разделить на три большие группы. Первая — это дорогие и качественные бренды, которые слишком боятся за свой международный бизнес, чтобы оставаться в России, но не настолько ненавидящие деньги, чтобы особо принципиально блокировать схемы параллельного импорта. То есть, сами они ничего у нас не продают, но купить каким-то образом их продукцию все-таки можно.

Вторая группа — это те производители, чьё оборудование продолжает оставаться доступным на рынке, но целые модельные ряды объявляются устаревшими, а на смену им приходят новые линейки устройств.

К третьей группе я хотел бы отнести оборудование, поставляемое под брендами, принадлежащими «НАГ». Оно разрабатывается, изготавливается и поставляется на базе ODM-партнерства, под контролем наших экспертов, хорошо понимающих проблемы отечественного рынка телекоммуникаций.

Компания НАГ поставляет оборудование производителей из всех трех групп, а наши специалисты всегда готовы помочь определиться с выбором в любой из них, дать рекомендации и посчитать затраты на разные схемы. Кроме того, наш сервисный центр оказывает гарантийное, постгарантийное и внегарантийное обслуживание практически для всех видов телекоммуникационного оборудования, представленного на российском рынке.

Начнём с первой группы.

Первая группа: в недавнем прошлом — лидеры рынка

Huawei

Компания Huawei завершила поставки своего оборудования на территорию РФ, однако в нашем портфеле решений доступны проверенные временем, изначально созданные для ADSL, платформы MA56XX-серии.

MA5608T

Возможна поставка как бюджетных комплектаций с одним блоком управления MCUD, так и с максимальной отказоустойчивостью за счет использования двух MCUD.

Максимальное количество ONU, подключаемых к данной OLT — до 4096. Модель поставляется как с 1xGE UPLINK- портами, так и с 10xGE.

MA5603T

Шасси той же продуктовой линейки, но большей вместительности. Несмотря на то, что шасси MA5603 имеет больший размер, чем MA5608, их стоимость практически идентична.

Шасси имеет 6 слотов для установки GPON-карт, что позволяет подключить до 12 288 ONU. В комплектации данного шасси поставляется 2 карты X2CS с 2×10G uplink-портами.

Недостатком данных платформ является отсутствие поддержки 10GPON линейных карт и завершение поддержки со стороны Huawei как по аппаратной, так и по программной части.

Cерия MA5800

В данной линейке представлен широкий выбор устройств различного размера, начиная от 1U MA5801, заканчивая самой «большой» OLT, размером 11U MA5800-X17. Хочу сразу обратить внимание на тот факт, что модель MA5800-X17 имеет нестандартную ширину и её установка возможна только в 21-дюймовую стойку.

MA5801-GP16

Самая компактная модель OLT Huawei, высотой всего 1U. Поставляется в исполнении 8xGPON-портов и 16xGPON-портов. Комплектуется блоками питания AC и DC, имеет 4 Uplink-порта, в т. ч. и 2×10GE.

MA5801-CG04

Является полным аналогом модели MA5801-GP16, за исключением PON-части: в ней реализовано 4xCOMBO-порта с поддержкой режимов GPON и XG-PON.

ZTE

Ещё одним надежным вендором, доступным на текущий момент в нашем магазине, выступает компания ZTE со своей двухюнитовой платформой ZTE C320.

У проверенной временем платформы C320, есть возможность установки до двух линейных карт, что равносильно 32xGPON-портам.

OLT ZTE C320 может поставляться как с DC-питанием, так и с AC/DC. В этом случае, в OLT устанавливается дополнительный модуль питания PRAM. При этом, для установки модуля питания, придется пожертвовать одной из двух карт управления: SMXA/1 с 1G Uplink-портами или SMXA/3 с 1/10G Uplink-портами.

В качестве линейных карт для данной OLT предлагается 4 модели:

GTGO на 8 GPON-портов, в комплекте 8 GPON-модулей класса C+.

GTGH на 16 GPON-портов, в комплекте 16 GPON-модулей класса C+.

GTGO+ на 8 GPON-портов, в комплекте 8 GPON-модулей c увеличенным оптическим бюджетом класса C++.

GTGH+ на 16 GPON-портов, в комплекте 16 GPON-модулей с увеличенным оптическим бюджетом класса C++.

Вторая группа: они не ушли, но возможны изменения в модельных рядах

BDCOM

Уже ставший культовым производитель BDCOM, в очередной раз порадовал новыми линейками OLT. Среди них есть как модульные платформы на 9 и 12U, так и 1U pizza-box-устройства.

Серия GP6606

Данная серия включает в себя две платформы.

GP6606−06 — это 9U мультифункциональная платформа, рассчитанная для установки до 4хGPON-карт, до 64xGPON-портов. Повышенная надежность достигается за счет использования двух независимых карт управления, а также двух карт с SFP+ Uplink-портами и двух блоков питания.

GP6606−10 — это 12U мультифункциональная платформа, рассчитанная для установки до 8хGPON-карт, до 128xGPON-портов. Повышенная надежность достигается за счет использования двух независимых карт управления, а так же двух карт с SFP+ Uplink-портами и двух блоков питания.

Серия GP3600

Данная серия представлена 1U GPON-устройствами Pizza-box и включает в себя:

GP3600−04B-2AC на 4xGPON-порта, но выпуск данной модели приостановлен из-за дефицита компонентов.

GP3600−08B-2AC на 8xGPON-портов.

GP3600−16B-2AC на 16xGPON-портов.

Серия P3600

Серия P3000 представлена тремя моделями OLT, на 4 — P3310D-2AC, на 8 и 16 портов P3600−08E-2AC и P3600−16E-2AC, соответственно.

В данный момент, самым бюджетным решением является модель P3310D-2AC, на 4-x EPON порта, с 4xGE COMBO-портами и без поддержки L3-функционала. В моделях на 8 и 16 портов уже есть 10Ge Uplink-порты и минимально необходимый L3-функционал.

С более подробным обзором линеек OLT BDCOM можно ознакомиться в этой статье.

C-DATA

FD1200

C-data в своем портфеле решений имеет аналогичные BDCOM, модели. Серия FD1200 включает в себя модель FD1204S на 4 порта, а также FD1208S и FD1216S на 8 и 16 портов, соответственно.

FD1600

Так же, как и в случае с GPON-линейкой, OLT доступны 3 вариантах: на 4, 8 и 16 GPON-портов, соответственно. Кроме того, в линейках GPON OLT C-DATA реализован необходимый минимальный функционал L3-маршрутизации. Все OLT имеют на своём борту SFP±порты, с поддержкой режимов 1/10G

FD1700

Модульная 1U OLT — это горячая новинка от C-DATA. С момента первого анонса прошло всего 2 недели. Эта OLT уникальна не только тем, что имеет модульную конструкцию при высоте всего лишь 1U, но и тем, что среди поддерживаемых карт расширения есть карта 10G-PON.

Возможные варианты установки линейных карт представлены на фото ниже. Всего шасси может вместить на своем борту до 32-x GPON-портов; до 16 XGPON-портов; до 8 10G EPON.

Также, C-DATA анонсировала обновленную версию CMS.

Основное отличие от обновленной CMS — это поддержка протокола TR-069, поэтому данный сервис может выступать как ACS-Server. CMS может контролировать работу абонентских устройств не через OLT, а «напрямую». Это позволит управлять сервисами, даже если управление с OLT было «потеряно». Кроме того, CMS от C-DATA является полностью бесплатной.

Добавлю, что OLT C-DATA не имеет так называемого вендор-лока, а это означает, что пользователи могут использовать альтернативные абонентские устройства. Совместимость ограничивается только поддержкой протоколов группы CTС и стандартов ITU-TG.984.2 Class B+/Class C+ / IEEE802.3ah

Третья группа: оборудование SNR

В ближайшее время в продаже появится обновленная линейка станционных терминалов SNR. В ней будут представлены 2 типа устройств.

GPON, модели на 4/8/16 портов, с поддержкой L3 функционала RIP, OSFP, BGP, ISIS.

GPON/XG-PON/XGS-PON OLT. Это долгожданная новинка, COMBO OLT, поддерживающая 3 режима работы: GPON 2.5G/1.25G, XG-PON 10G/2.5G, XGS-PON 10G/10G.

Это значит, что 8-портовая OLT может быть использована для закрытия целого пула вопросов и применяться одновременно в GPON, XG-PON и XGS-PON-сетях. Помимо уже привычных SFP+ 10G аплинк-портов, OLT оснащена и двумя QSFP+ 40G / QSFP28 100G-портами.

Совместимость оборудования SNR с другими вендорами

Наши абонентские устройства SNR и BO полностью совместимы с оборудованием C-DATA и BDCOM. Для удобства выбора приложу таблицу с основным функционалом и названием моделей.

Заключение

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

На рынке можно найти практически любое оборудование, которое вы используете на своих сетях, и даже получить техническую поддержку для его эксплуатации. Можно частично заменить оборудование на модели другого производителя или на устройства другого модельного ряда, будучи уверенными в его совместимостидля решения ваших задач. Можно заменить не только все оборудование, но и воспользоваться возникшими проблемами в качестве решающего фактора для перестройки всей сети вообще, создания потенциала для роста, усложнения и масштабирования на много лет вперёд.

Любой кризис всегда содержит в себе возможность для перестройки и адаптации. Главное в этом вопросе — опереться на опыт и экспертное мнение специалистов, способных преодолеть любую проблему и решить любую задачу.

И такие специалисты в нашей стране есть. :)

Однако, в 2022 году некоторые иностранные компании приняли решение частично или полностью прекратить деятельность на территории РФ. В данной статье предлагается рассмотреть оборудование для мониторинга технологических параметров и удалённого управления в телекоммуникационной среде, предлагаемую отечественными  производителями.

SNR

SNR — это комплексная линейка товаров, включающая в себя целый спектр оборудования для построения сетей связи и IT-инфраструктуры в самых различных областях. В частности, компания занимается разработкой собственных решений для мониторинга технологических параметров и удалённого управления телекоммуникационным оборудованием.

SNR-ERD — серия компактных контроллеров, выполняющих задачи по сбору и передаче информации от датчиков, модулей расширения на web-интерфейс устройства или в систему мониторинга по SNMP-протоколу. А также, управление исполнительными устройствами.

ERD-4 - это линейка контроллеров в компактном металлическом корпусе с возможностью устанавливать на DIN-рейку или плоские поверхности (кронштейны для крепления входят в комплект поставки). Модель выпускается в двух вариантах: без GSM-модуля (SNR-ERD-4s) и с GSM-модулем (SNR-ERD-4s-GSM). В устройстве есть пять универсальных портов DIO, которые можно настроить для работы как на «вход» (подключение датчиков с типом выхода «сухой контакт»), так и на «выход». Есть аналоговый вход для измерения постоянного напряжения (до 76 В) или тока (с датчиков 0−20 мА). Устройство имеет два независимых конвертера: RS232 — Ethernet, и RS-485 — Ethernet, которые могут работать одновременно. В составе устройства также есть силовое реле с перекидным контактом, позволяющее управлять нагрузкой с напряжением питания 230 В и током потребления до 10 А. 

Отдельный вход для подключения «датчика фазы». Вход для подключения климатических датчиков, работающих по протоколу 1-wire (до 10 шт.) или Single Wire (1 шт). Устройства ERD-4 по протоколу Megatec могут получать данные с ИБП. Версия с GSM-модулем позволяет управлять устройством ERD или получать оповещения посредством SMS-сообщений. Также, на устройстве с GSM-модулем можно организовать резервный канал связи через сотового оператора. В серии ERD-4 реализованы протоколы: MQTT, L2TP, SNMP, оповещения на E-mail, Web-интерфейс.

К устройству подключаются следующие модули расширения: модули дискретных входов (на 8 дискретных входов: SNR-RScounter-8i-SMART или SNR-RScounter-16i-SMART), релейный модуль на 6 каналов SNR-SMART-RELAY-6×16-DIN, удлинитель-расширитель шины 1-wire SNR-RSsensor. Для управления нагрузкой к дискретным выходам подключаются блоки розеток серии SNR-SMART.

Базовая версия ПО имеет предустановленные сценарии такие как: гидролок, термостат, сетевая диагностика. Возможность задать расписание событий, управлять аналогичным устройством по сети Ethernet. Возможность сохранить конфигурацию устройства в файл с последующей загрузкой в аналогичное устройство. В версии ПО с настраиваемой логикой, можно составить до 6 собственных сценариев поведения устройства.

Также, существуют младшие модели устройств ERD-4 - это контроллеры серии ERD-2.3, ERD-2s, обладающие меньшим функционалом, таким как: измерение температуры/влажности в одной точке, подключение до четырёх датчиков типа сухой контакт, два дискретных выхода, аналоговый вход (измерение постоянного напряжения). Вход для подключения «датчика фазы».

Устройства SNR-ERD сочетают такие качества как компактность и функциональность, вследствие чего отлично подходят для установки в небольших телекоммуникационных шкафах, стойках, серверных и ЦОД, из-за своего размера, там где есть необходимость применить надежное и компактное устройство. А также, на удаленных объектах, где отсутствует проводной интерфейс или бывают перебои со связью.

Netping

Компания ООО «Алентис Электроникс» (торговая марка Netping) является разработчиком и производителем линейки устройств мониторинга и управления питанием (IP PDU) под торговой маркой NetPing.

Устройства, условно, можно разделить на категории: стоечные контроллеры, компактные контроллеры, стоечные устройства IP PDU, компактные устройства IP PDU. Стоечные контроллеры выпускаются в версии с GSM/3G-модулем и без модуля. Устройства управления IP PDU и стоечные и компактные выпускаются в версии с GSM/3G модулем и без такового.

Все устройства имеют web-интерфейс, выполненный в едином стиле, протокол передачи данных SNMP, уведомления по E-mail, журнал событий.

Серия устройств Server Solution

Серия устройств Server Solution выпускается в 19″ конструктиве (например NetPing-server-solution-v7-GSM3G). Есть возможность подключать климатические датчики температуры (до 8 шт.) и влажности (до 4 шт.) по шине 1-wire. 12 портов DIO. Два реле с перекидным контактом для управления низковольтной нагрузкой постоянного тока. Аналоговый вход для датчика с выходом токовой петли. В версии GSM установлен ионистор, который позволяет работать устройству непродолжительное время после отключения питания, для возможности отправки уведомления.

Любые устройства Netping (IP PDU или контроллеры мониторинга), которые не имеют GSM/3G-модуля в составе устройства, для работы по GSM-каналу могут быть подключены к модулю расширения Netping SMS. Устройство Netping SMS универсально, и может быть использовано с любыми устройствами, поддерживающими протокол SNMP v1.

Устройства IP PDU

Устройства выполняются на 2, 4 и 8 управляемых розеток в соответствующем форм-факторе: компактное устройство в пластиковом корпусе на 2 розетки, в металлическом корпусе 1U для установки в стойку 10'' или 19'' на 4 розетки, в металлическом корпусе 1U для установки в стойку 19'' на 8 розеток.

Интересны модели тем, что можно управлять каждой розеткой в отдельности. Серии устройств стоечного исполнения NetPing 4/PWR-220 v8 (например NetPing-4/PWRv8.4/ETH) и NetPing 8/PWR-220 v7 (например NetPing-8-PWRv7.2-GSM) передают данные о мощности потребления по каждой розетке. Устройства серии NetPing 8/PWR-220 v7 можно подключить к двум независимым вводам питания, реализована функция АВР. Ко всем устройствам IP PDU можно подключить климатические датчики температуры и влажности, датчики типа «сухой контакт».

Устройства NetPing представлены широким ассортиментом, позволяющим точно подобрать нужный тип оборудования для решения поставленной задачи. В устройствах хорошо реализована функция гибкой логики даже в самой бюджетной модели NetPing IO V4. Хорошо развита линейка периферийных устройств, комплектующих и датчиков.

Elemy

Компания предлагает устройства для автоматического ввода резервной линии питания (АВР). Блоки распределения питания (iPDU) с функциями мониторинга параметров микроклимата. Контроллер мониторинга параметров с датчиков температуры, влажности, напряжения, датчиков типа «сухой контакт».

Поскольку одним из первых продуктов компании был электронно-механический АВР ATS-1201, в каталоге компании широко представлены устройства для автоматического ввода резерва и стоечные переключатели. В декабре 2022 года была представлена новинка - серия интеллектуальных блоков распределения питания в вертикальном ZeroU-исполнении iPDU 59XX.

Устройство интересно своей функциональностью, возможностью изготовить нужную комплектацию согласно вариантам исполнения. Например, устройство может управлять питанием и осуществлять мониторинг параметров как группы розеток, так и каждой розеткой в отдельности. Также, устройство позволяет подключить пару датчиков температуры и влажности, имеет 4 дискретных входа. Для отслеживания параметров устройства и управления предусмотрен web-интерфейс. Возможна интеграция в SCADA/DCIM по протоколам: SNMP и ModBus-TCP.

В апреле 2022 года (согласно новостной ленте с официального сайта Elemy) компания приступила к разработке целой линейки устройств для обеспечения удаленного мониторинга объектов ИТ-инфраструктуры. Данная система должна будет заменить собой применяемые ранее комплекты зарубежных производителей. Ждём новостей, а пока предлагается к применению Контроллер мониторинга и управления: CCU-1001.

Устройство позволяет осуществлять удаленный мониторинг температуры и влажности, напряжения, состоянии оборудования в шкафу, положении дверей. Дистанционное управление отдельными элементами и приборами в шкафу.

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

Предусмотрено подключение комбинированных датчиков температуры и влажности, наличие 16 дискретных входов и 8 дискретных выходов для управления внешними устройствами. Также, предусмотрен алгоритм поддержания микроклимата в заданном пространстве, есть специализированные выходы для управления питанием активного оборудования. Для отслеживания параметров устройства и управления предусмотрен web-интерфейс. Возможна интеграция в SCADA/DCIM по протоколам: SNMP и ModBus-TCP.

У данной компании широко представлена линейка устройств для управления питанием активного оборудования. Серия интеллектуальных блоков распределения питания в вертикальном ZeroU-исполнении iPDU 59XX позволяет следовать современным принципам при проектировании серверных комнат или центров обработки данных.

Интеллект-модуль

Компания производит управляемые блоки розеток (PDU), контроллеры мониторинга с возможностью подключения датчиков контроля параметров окружающей среды, дискретных входов, дискретных выходов, релейных модулей, модулей передачи данных со счётчиков электрической энергии. Устройства представлены как в стоечном исполнении, так и в варианте крепления на DIN-рейку. На сайте компании в разделе Технические решения описаны варианты применения устройств. Интересные кейсы по мониторингу показаний электросчётчиков и состоянию автоматических выключателей, а также управление релейным модулем по сети Ethernet сигналами с модуля дискретных входов.

Интересный вариант PDU на 8 розеток LPowerNode 8PDU, заявлен как новинка.

Позволяет управлять каждой розеткой в отдельности. По каждой розетке ведётся учёт параметров электроэнергии. Предлагаются варианты исполнения с общим выходным током до 16 A или 40 А. Есть возможность подключения климатических датчиков, датчиков типа «сухой контакт». Устройство имеет web-интерфейс, обеспечивает передачу данных по протоколам SNMP (версий 1, 2С, 3), ModBus/TCP. Поддерживаются логические схемы, расписание, журнал событий на 4000 элементов. Есть DEMO-версия для ознакомления с устройством.

Контроллер мониторинга предлагается рассмотреть на базе системы iNode 19D, которая предназначена для дистанционного контроля дискретных датчиков (работающих по принципу «замкнуто-разомкнуто»), цифровых датчиков температуры и влажности, контроля параметров сети переменного напряжения, а также управления силовыми реле по сети Ethernet.

Интересное инженерное решение реализовано в виде блочного каркаса 19''-стандарта с 16-ю посадочными местами (слотами) для установки контроллера и модулей. Позволяет гибко сконфигурировать систему мониторинга. Система позволяет контролировать до 128 дискретных датчиков, либо управлять 24-мя гальванически изолированными перекидными контактами силовых реле. Возможность подключения модулей расширения с функцией счётчика импульсов на входах, контролем наличия напряжения, контролем цифровых климатических датчиков (температура, давление, влажность), контролем параметров электропитания 1/3-х фазной сети переменного тока, контролем параметров счетчиков электроэнергии, аналоговых датчиков (измерение постоянного напряжения, тока, режим токовой петли 4/20 мА). Устройство имеет web-интерфейс, обеспечивает передачу данных по протоколам SNMP (версий 1, 2С, 3), ModBus/TCP. Возможность отправки измерительных данных от подключенных датчиков на удаленный TCP-сервер в формате XML или JSON. Встроенный журнал событий на 1200 записей.

Также, предлагается вариант контроллера для установки на DIN-рейку: сетевой контроллер iNode CE-35D. Система мониторинга строится также по модульному принципу. Модули устанавливаются на DIN-рейку. Доступна ознакомительная версия интерфейса модуля CE-35D.

У компании "Интеллект модуль" довольно интересно и функционально спроектированы устройства. Например, система мониторинга iNode 19D, построенная по модульному принципу, позволяет точно сконфигурировать нужную комплектацию по типу и количеству интерфейсов. При необходимости в процессе эксплуатации система может быть масштабирована путём установки дополнительных модулей либо подключением внешних.

OSNOVO

OSNOVO — это линейка оборудования для передачи, распределения и коммутации сигналов для: систем аналогового и IP-видеонаблюдения, систем безопасности, мультимедийных систем.

Система мониторинга OSNOVO строится на контроллере TMS-01.

Контроллер позволяет подключать датчики температуры, влажности, напряжения, а также датчики типа «сухой контакт». Производитель рекомендует использовать систему мониторинга с датчиками OSNOVO, такими как: TMS-STH (датчик температуры и влажности), TMS-SL (датчик фазы), TMS-SV (датчик сетевого напряжения). Контроллер имеет встроенный web-интерфейс, передаёт данные по протоколу SNMP.

Совместно с системой мониторинга предлагается программное обеспечение собственной разработки OSNOVO Monitoring System, которое позволяет организовать централизованную систему мониторинга технологических параметров в одном окне. В данное программное обеспечение интегрируются все продукты торговой марки OSNOVO, что также очень удобно с точки зрения эксплуатации. Предусмотрена гибкая система лицензирования в зависимости от количества требуемых переменных. Лицензия действует бессрочно.

К сожалению, у компании Osnovo представлен только один вариант контроллера, который позволяет подключать минимальный набор датчиков, и не имеет модулей расширения, что ограничивает сферу применения. Устройство TMS-01 разумно использовать для контроля параметров телекоммуникационного шкафа, стойки. Приятный бонус от компании -  на всю продукцию гарантия составляет 60 месяцев. Также, отсутствуют варианты устройств для удалённого управления оборудованием.

Технотроникс

Компания «Технотроникс» является разработчиком и производителем комплексных программно-аппаратных систем мониторинга удаленных и распределенных объектов.

Компания предлагает решения для мониторинга параметров АКБ, ИБП, снятие показаний со счётчиков, контроль температуры, влажности, параметров электропитания, контроль параметров датчиков с типом сигнала «сухой контакт». Управление питанием оборудования. Авторизация доступа на объект.

Оборудование передаёт данные и управляется программным комплексом «Технотроникс.SQL», также возможна передача данных по протоколу SNMP. К программному комплексу «Технотроникс.SQL» возможно подключать модули расширения, такие как: 

• Подсистема «Ресурсоучёт».
• Подсистема «Технотроникс.Уведомления» Email.
• Подсистема «Технотроникс.Уведомления» Telegram.
• Подсистема «SMS» и другие.

Ещё один интересный программный продукт - Облако cloud.ttronics.ru — это сервис, предназначенный для просмотра показаний с приборов учета и мониторинга различных параметров через Интернет (температура, влажность, напряжение и др.). Отличное готовое решение для тех, кто не хочет заморачиваться с приобретением и установкой специализированного программного обеспечения.

Самый многофункциональный контроллер КУБ-БС предназначен для мониторинга базовых станций, крупных климатических телекоммуникационных шкафов, контейнеров и не только. Способен закрыть все потребности объекта в мониторинге.

Устройство выполнено в стандартном 19-дюймовом конструктиве, высотой 1 юнит. Реализована возможность подключения датчиков температуры и влажности, дискретные и аналоговые входы, релейные выходы с перекидным контактом, дискретные выходы, конвертеры RS232 и R485 в Ethernet. Устройство оснащено GSM-модулем.

Также, предлагаются более компактные и узкоспециализированные контроллеры, например для контроля параметров АКБ: АКБ-12/485 и МКА4+.

Устройства позволяют осуществлять:

• Поэлементный контроль напряжения и температуры аккумуляторов (АКБ).
• Контроль тока заряда/разряда/нагрузки АКБ, соединенных в группу (группы).
• Контроль температуры помещения аккумуляторной комнаты.
• Передача данных в диспетчерский центр.

Компания «Технотроникс» предлагает интересные решения для задач отслеживания параметров как группы аккумуляторных батарей, так и каждого аккумулятора в группе. Широкая линейка контроллеров различных модификаций, позволяет однозначно сделать выбор в пользу нужного варианта. Функциональный программный комплекс с различными подключаемыми модулями является мощным инструментом для пользователей.

Изучив продукты и решения представленных компаний, можно сделать вывод, что уход зарубежных компаний не оставит нашу телекоммуникационную отрасль без систем мониторинга и удалённого управления устройствами. А где-то, даже сподвигнет на разработку новых технологических решений. Каждая представленная компания ориентирована на свой сегмент рынка. Все предложения достойны внимания.

Список сайтов, использованных источников:

1. https://shop.nag.ru/
2. https://netping.ru/
3. https://www.elemy.ru/
4. https://intellect-module.ru/
5. https://osnovo.ru/
6. https://ttronics.ru/