FAQ

Поддержка Bypass реализована для карт производства Silicom 40 GbE, 10 GbE и 1 GbE. Многопортовые сетевые карты имеют специальный режим “Bypass”. Когда на сетевой карте включен этот режим, трафик для сетевой карты физически замыкается между двумя портами и таким образом минует обработку непосредственно на сетевой карте и, соответственно, на платформе.

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

*Включение этого режима на сетевой карте следует рассматривать как аварийную ситуацию.

Платформа полностью прозрачна для применения протокола агрегации каналов LACP при соблюдении следующий условий:

• порты обработки трафика принадлежат одному кластеру
• порты настроены симметрично и правильно подключены
• трафик от/к Абоненту (IP-адреса источника) проходят через одни и те же порты обработки трафика.

В качестве управляющего протокола для LAG может применяться как стандартный LACP (IEEE 802.3ad), так и проприетарные, например PAgP.

*Протоколы LAG имеют довольно длительное время «сходимости» вплоть до 30 секунд (без использования специальных настроек), что может сказаться на корректном прохождении трафика через платформу.

NetFlow v5 ограничивается потоками IPv4. Выбор полей, которые можно экспортировать с использованием этой версии, тоже ограничен.

IPFIX — иногда его называют NetFlow v10. Здесь вводятся две новые концепции мониторинга потоков: во-первых, допускается использование шаблонов, а во-вторых, пользователь имеет возможность «заглянуть» в пакеты достаточно глубоко и выбрать для мониторинга интересующие его поля. IPFIX позволяет выбирать из заголовка IP почти все поля, все типы флагов TCP и другую информацию, в том числе теги VLAN и адреса URL.

Преимущества IPFIX по сравнению с традиционным NetFlow v5:

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

Ротация файлов обеспечивает ежедневное резервное копирование суточного лога. По умолчанию этот процесс осуществляется в часы с наименьшей нагрузки на систему. Глубина хранения логов определяется в конфигурации /etc/logrotate.d/fastdpi параметр maxage, значение указывается в сутках.

* Опционально — эта опция может быть добавлена к основной лицензии за дополнительную плату.

Довольно ресурсоемкий модуль: предъявляет повышенные требования в части CPU, скорости и емкости RAM, опционально быстрый HDD, но предпочтительнее SSD с поддержкой NVMe.

• Один процессор с поддержкой инструкций SSE 4.2, начиная с Intel Nehalem и AMD EPYC Zen2 с количеством ядер 4 и более, базовой тактовой частотой от 2.6 Ггц и выше.
• Также на сервере должен быть отключен HyperThreading.
• Поддержка Bypass реализована для карт производства Silicom 40 GbE, 10 GbE и 1 GbE
• Операционная система: CentOS 8+ (x64)
• Минимально требуется 3 порта: один для управления по SSH (любой чипсет), два для обработки трафика — сетевые карты на чипсетах с поддержкой технологии DPDK.

Рекомендуется использовать только протестированные карты на чипсетах Intel (с количеством портов 2, 4 и 62):

1GbE интерфейсы

• e1000 (82540, 82545, 82546)
• e1000e (82571, 82572, 82573, 82574, 82583, ICH8, ICH9, ICH10, PCH, PCH2, I217, I218, I219)
• igb (82573, 82576, 82580, I210, I211, I350, I354, DH89xx)
• igc (I225)

10GbE интерфейсы

• ixgbe (82598, 82599, X520, X540, X550)

10GbE и 40GbE интерфейсы

• i40e (X710, XL710, X722, XXV710)

100GbE интерфейсы

• mlx5 (Mellanox ConnectX-5 Ex)
• ice (Intel E810) — не рекомендуем, есть проблемы в intel firmware на карте: не пропускает GRE туннели

В случае, если используется только один сервер с DPI, модуль PCRF возможно разместить на том же сервере. В вариантах, когда используется несколько DPI (для распределения нагрузки/резервирования), имеет смысл вынести PCRF на отдельный сервер.

Требования: не менее 2 Гбайт ОЗУ, 2 ядра CPU от 2,5 Ггц, дисковое пространство от 128Gb.

Для управления — отдельный сетевой порт (но не менее 100 Мбит/сек) на любом чипсете поддерживаемый операционной системой.

Операционная система: CentOS 8+ (x64).

Модуль требователен к количеству ядер процессора, оперативной памяти и скорости дисковой подсистемы. Требования: не менее 16 Гбайт ОЗУ, 4 ядра CPU от 2,5 Ггц, дисковая подсистема для БД от 1000 Мб на SSD-накопителе, для приложения от 128 Мбайт.  Расчет хранения: В среднем на 10 Гбит/сек трафика DPI необходимо около 25 Гбайт хранения данных в БД.

Для управления — отдельный сетевой порт (но не менее 1 Гбит/сек) на любом чипсете, поддерживаемый операционной системой. Операционная система: CentOS 8+, отключенный файл подкачки (swap).

Поток NetFlow отправляется на коллектор с выделенного интерфейса DPI, обычно используется mgmt интерфейс, по которому осуществляется доступ по SSH, интеграция с RADIUS, и т.д.

*Поток одного типа может быть только один. При необходимости отправки в несколько источников используется реэкспорт с модуля QoE или других коллекторов.

Пропускная способность, необходимая для экспорта данных NetFlow, обычно составляет менее 0,5% от общего потребления полосы пропускания. Например, если вы отслеживаете канал с использованием 100 Гбит/с, DPI будет использовать менее 0,5 Гбит/с для экспорта данных NetFlow.

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

СКАТ обеспечивает анализ и обработку трафика с помощью применения функций контроля и управления трафиком. Благодаря сочетанию технологии DPI, программного обеспечения BRAS/BNG и CG-NAT, система решает большинство проблем провайдера.

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

Программный маршрутизатор
Компонент, который объявляет и получает маршруты через OSPF, BGP и другие протоколы динамической маршрутизации, поддерживаемые demon роутером. В текущей реализации используется BIRD.

PCRF
Обеспечивает взаимодействие платформы с AAA-сервером оператора по протоколу RADIUS (AAA — Authentication, Authorization, Accounting).

QoE Stor — набор приложений для сбора и хранения информации о трафике.

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

Основные функциональные задачи DPI:

• Применение политик скорости к всему трафику или индивидуально на абонента
• Применение сервисов платформы (CG-NAT, Белый список, Фильтр запрещенных сайтов и т.д.)
• Формирование экспорта информации о трафике в различных форматах (NetFlow, IPFIX-clickstream, IPFIX-nat, IPFIX-flow и т.д.)
• Функции BRAS (IPoE, PPPoE, DHCP L2)

Компонент, отвечающий за взаимодействие платформы с AAA cервером оператора связи по протоколу RADIUS. (АAA — Authentication, Authorization, Accounting). Используется, если на Платформе DPI включены функции BRAS/BNG.

Компоненты DPI и PCRF связываются друг с другом по внутреннему протоколу взаимодействия через TCP/IP стек. PCRF может быть вынесен как на отдельный физический или виртуальный сервер, так и работать на том же сервере вместе с DPI.
В случае использования нескольких DPI, используется схема 1xPCRF : NxDPI.

Если в сети уже реализованы функции авторизации, то DPI включается после BRAS/BNG до NAT. Таким образом в анализируемом трафике будут видны реальные private IP абонентов.

В случае, если платформа выполняет функции BRAS/NAT/DPI, включение осуществляется в ядре сети между уровнем агрегации и пограничным роутером.

Платформа DPI всегда имеет порты назначения: к Абоненту — порт подключается к сети передачи данных и к Интернет — порт подключается к пограничному маршрутизатору.

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

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

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

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

Существует возможность передачи на платформу трафика от/к Абонентам через «зеркало», используя оптический сплиттер или режим SPAN на маршрутизаторе. В этом режиме платформа может обеспечить фильтрацию по черным спискам (аналогично «асимметричному» режиму), сбор статистики по трафику в QoE Stor, Уведомление абонентов через HTTP Redirect. Для получения информации о принадлежности IP к логинам применяется Radius монитор, который выгружает в UDR DPI связки IP-Login. 

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

*Нужно понимать, что сетевой интерфейс платформы будет работать только на «прием» трафика. Так, например, если в этом режиме подать на порт 10 Гбит/сек, «зеркалируемый» трафик в объеме 8 Гбит/сек входящего (к абонентам) и 5 Гбит/сек исходящего (от абонентов), то суммарный трафик составит 13 Гбит/сек, что явно выше возможностей физического порта приема.

В случае необходимости обработки трафика большего объема, чем производительность одной DPI платформы (100G full duplex), устанавливаются дополнительные модули DPI. Для корректной работы необходимо выполнить условие по организации симметрии трафика (все пакеты в рамках одной сессии должны проходить через одно устройство DPI).

Симметричность можно обеспечить с помощью балансировки по SRC/DST IP на коммутаторах и маршрутизаторах или с помощью установки специальных балансировщиков — Packet Broker.  

• бонусная программа
• вставка рекламных баннеров
• блокировка рекламы
• черный список сайтов
• белый список сайтов
• уведомление абонентов (при запросах по HTTP)
• кеширование
• DDoS защита
• сбор NetFlow статистики для биллинга, аккаунтинг
• CG-NAT
• запись трафика абонента в PCAP
• ACL (mini firewall)
• отведение трафика на внешние платформы
• маркетинговые кампании

Предлагается использовать SNMP agent, который устанавливается на сервер для отправки информации в имеющуюся систему оператора.

Многие операторы связи используют систему мониторинга Zabbix. В этом случае на сервера Платформы устанавливается zabbix-agent, производится его стандартная настройка и подключение к серверу zabbix. В качестве шаблона, необходимо использовать стандартный шаблон “Template OS Linux” — для наблюдения за основными параметрами. А также подключить кастомный шаблон “Template DPI”, позволяющий наблюдать за специфическими параметрами fastDPI. Доступность zabbix-agent для Платформы позволяет использовать всю мощь этой системы мониторинга.

В базе данных системы СКАТ содержится соответствие всех адресов их автономным системам, таким образом можно понять к какой ASN относится трафик и соотнести это с географическим расположением владельца AS. В данный момент прямой интеграции с сервисами локации IP по географическому расположению нет.

Да, есть возможность это настроить. Вы можете управлять как функцией BRAS, так и DPI на конкретную подсеть или автономную систему.

Для корректной работы СКАТ требуется отключать Hyper-Threading. СКАТ работает только с физическими процессорными ядрами.

Да, для реализации более 100 Гбит/с на одном сервере. Возможно использование 2,4 сокетов и достижение 400 Гбит/с. Предпочтительнее использовать однопроцессорные системы с достаточным количеством ядер. 

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

1. Приобрести стандартный сервер x86 любого производителя.
2. Использовать уже имеющееся оборудование.
3. Развернуть BRAS как виртуальную систему (компонент VNF на сервере eSXI, KVM, Hyper-V).

• Пользователь делает запрос через PPP (PAP, CHAP, MS-CHAPv2).
• СКАТ обрабатывает запрос и формирует Access-Request к Radius серверу через PCRF.

Acct-Session-Id = «001122334455667788»
User-Name = «login04»
User-Password = «password»
Calling-Station-Id = «84:16:f9:05:8b:12»
NAS-Port-Type = 5 (Virtual)
NAS-Port = 0
NAS-Port-Id = «321/654»
NAS-IP-Address = “5.5.5.5”
VasExperts-Service-Type = 3

• Radius генерирует ответ Access-Accept, указывающий имя пула DHCP-сервера из которого будет назначен частный IP-адрес.

Session-Timeout = 86400
User-Name = «login04»
Framed-Pool = default
VasExperts-Policing-Profile = «rate_50mbits»
VasExperts-Service-Profile = «11:CG-NAT_pool_001»

• Сервер PCRF делает запрос DHCP к серверу DHCP и получает параметры для конкретного абонента.
• Логин (полученный от Radius) и IP-адрес (полученный от DHCP-сервера) связываются вместе. Полисинг и сервисные данные из Radius применяются к логину.
• СКАТ генерирует ответ пользователю об успешном установлении PPPoE-соединения.

Маршрутизатор объявляет маршрут (BGP, OSPF) в NAT-пул в момент его создания.

Для абонентов с публичными адресами объявление делается после авторизации абонента.

• По IP адресу в пакете, полученном при использовании BRAS в режиме L3.
  
• По PPPoE пакету — полученного со стороны абонентского порта PPPoE пакета на авторизацию (PADI). В нем можно идентифицировать абонента по login, mac-адресу, qinq меткам.
• По DHCP пакету — из полученного со стороны абонентского порта  широковещательного DHCP Discovery пакета в режиме L2 можно получить информацию для идентификации абонента по mac-адресу или qinq-метке.

Нет, если SSH будет перезапущен, он продолжит работать в том же режиме.

• DHCP L3  — Абонент получает IP-адрес от DHCP сервера (никак не связан со СКАТ) и через маршрутизируемую сеть попадает на СКАТ. Где по Source IP проходит авторизацию в Биллинге (полисинг, сервисы) и попадает на следующий за СКАТ маршрутизатор (IP при этом может транслироваться с помощью CG-NAT).
• DHCP L2 — Абонент получает IP-адрес через СКАТ DHCP Proxy или DHCP Relay и проходит авторизацию в Биллинге. Дальше терминируется СКАТом и попадает на следующий за ним маршрутизатор.
• Static L2 — Абонент имеет фиксированный IP-адрес, по данным, полученным СКАТ из ARP-запроса к шлюзу проходит авторизацию в Биллинге, терминируется СКАТом и попадает на бордер.
• PPPoE — Абонент поднимает PPP туннель со СКАТ, через логин/пароль проходит авторизацию в Биллинге, терминируется СКАТом и попадает на бордер.

Для приема и обработки статистики существуют следующие варианты:

• Бесплатный продукт NFSEN в связке с NFDUMP — подходит только для приема NetFlow v5 для анализа статистики по протоколам и направлениям.
• ipfixreceiver — используется для приема IPFIX, сохраняет его в локальном файле.
• Модуль QoE Stor в связке с графическим интерфейсом DPIUI2.

Рекомендуем использовать QoE Stor с целью получения максимального эффекта от выгружаемой статистики из DPI модуля.

Модуль Quality of Experience (QoE) — это программный продукт для сбора статистики и оценки качества восприятия услуг.

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

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

Для работы с IPFIX (NetFlow v10) используется четыре составляющие:

1. Экспортер потока: устройство, отвечающее за сбор информации о потоках и ее экспорт в коллектор потоков — СКАТ DPI (DPI модуль).
2. Коллектор: приложение, которое получает экспортированную информацию о потоке — ipfixreceiver2 в составе QoE Stor.
3. Анализатор потока: приложение, которое анализирует информацию о потоках, собранную коллектором. Информация о потоке записывается для хранения и анализа в БД ClickHouse.
4. Интерфейс управления:  приложение, которое позволяет эффективно визуализировать статистику о потоке и управлять всей системой контроля и анализа трафика (СКАТ DPI) — графический интерфейс пользователя DPIUI2.

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

1. Процессор (CPU) 2.5 ГГц — 1 шт. (требуется поддержка набора инструкций SSE 4.2. Тактовая частота менее важна. Например, 16 ядер с 2600 МГц лучше, чем 8 ядер 3600 МГц)
2. Оперативная память (RAM) — от 16 Гб (памяти должно быть не меньше, чем объем запрашиваемых данных. Чем больше памяти, тем лучше производительность при построении отчетов. Чем больше памяти, тем меньше нагрузка на диск. Минимальное требование — 16Гб. Всегда отключать файл подкачки)
3. Жесткий диск (SSD крайне желателен) — от 500 Гб (требуемое место на диске от 16ГБ на каждый день хранения в зависимости от трафика. Подсчитано, что 10 Гбит/с среднесуточного трафика генерирует примерно 25 ГБ данных за один час в QoE Stor). Калькулятор расчета представлен на Wiki.
4. Операционная система — CentOS 8+
5. Сетевая плата (NIC) — от 1 Гбит/сек.

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

DPI-сервер выполняет роль сенсора. Он логирует информацию о потоке  в партиции, и отправляет их в коллектор QoE Stor (периодичность по умолчанию — 1 мин.). QoE Stor, получив данные,  переводит их в табличные значения (Сырой лог), затем агрегирует(Агрегированный лог).

В QoE Stor есть 4 типа сырых логов:

• сырой полный NetFlow, формируется из потока netflow_full,
• сырой Clickstream, формируется из потока ipfix_tcp,
• сырой  GTP Flow, для мобильных сетей,
• сырой NAT Flow,  информация о NAT трансляциях. 

4 типа агрегированных логов:

• NetFlow,
• Clickstream,
• GTP Flow,
• NAT Flow. 

Сырые логи состоят исключительно из таблиц со всей собранной информацией по потокам: начало/конец/ID сессии, IPv4/v6 адреса источников/получателей до/после NAT, порты источников/получателей, АС получателей и т.д. Шаблон таблиц описан в разделе Форматы NetFlow.

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

Да, можно, как в схеме “в разрыв”, так и в схеме “зеркалирования”.

В базе данных ClickHouse.

• MPLS – да
• GRE – да, но только на условии, что трафик в туннеле не шифрованный
• GTP –  да, тегированный трафик СКАТ разбирает без проблем (в том числе QinQ)

Ориентировочно 4 терабайта за 6 месяцев при среднесуточной нагрузке в 1 гигабит/с. Более точные данные можно узнать экспериментально.

Наши работы по настройке, внедрению и тестированию занимают до 60 рабочих дней.

Это время не включает в себя:

• время необходимое на установку серверов СОРМ на узле оператора
• время на подготовку сети оператора для организации подачи трафика на СОРМ
• а также время на подготовку и доработку выгрузок абонентских данных, и другие возможные работы со стороны оператора.

По нашему опыту, внедрение СОРМ2 занимает от 2 недель до 9 месяцев с момента заключения договора. СОРМ3 от 6-18 месяцев с момента заключения договора.

После внедрения ПО, оператору необходимо оплачивать техническую поддержку СОРМ.

После истечения первого года стоимость поддержки ПО 12% от стоимости лицензий за один год.

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

В техподдержку ПО входит:

• мониторинг состояния СОРМ 24/7
• реакция на проблемы в формате NBD
• обновления ПО
• перенос ПО и баз данных с сервера на сервер при необходимости.

Цена зависит от многих факторов:

• Стоимость ПО. Мы являемся производителем ПО и даем на ПО 50% скидку от прайсовой цены операторам из регионов, вошедших в состав РФ в 2022 году.

• Стоимость оборудования. Наши партнеры могут предложить решения под ключ, в которые будет входить оборудование и наше ПО. Также для оптимизации затрат на СОРМ2 и 3 можно приобрести только ПО, собрав оборудование по нашей спецификации.

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

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

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

Оператор не может самостоятельно установить и настроить ПО СОРМ, поскольку дистрибутивы СОРМ — информация ограниченного распространения. Доступ к настройкам СОРМ и данным в ИС СОРМ может быть только у вендора ПО в процессе внедрения и у управления ФСБ после сдачи в эксплуатацию.

Оператор может сам собрать оборудование СОРМ 2 и 3 по нашей спецификации. Обязательным условием является наличие датчика вскрытия корпуса сервера.

Однако оборудование СХД собрать самостоятельно нельзя. К нему предъявляются требования к сертификации по 719 Постановлению Правительства «О подтверждении производства промышленной продукции на территории Российской Федерации». СХД продается только в составе аппаратно программных комплексов через наших партнеров. Комплекс включает ПО VAS Experts и оборудование, сертифицированное по ПП 719.

Для подключения к ПУ требуется организация отдельного VLAN от оборудования СОРМ до порта ФСБ. Отдельная физическая линия не нужна, обычно такой канал организовывается через вышестоящего оператора.

Поставщик пульта управления и поставщик СОРМ не должны быть одинаковыми. ПУ и СОРМ обмениваются данными по унифицированным протоколам.

Соответствие единым требованиям подтверждается в процессе сертификации ПУ и СОРМ в системе сертификации в области связи. Решения СОРМ от VAS Experts имеют все необходимые сертификаты.

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

Наша практика работы с популярными поставщиками биллинговых решений:

• LANbilling полностью соответствует нашим требованиям к форматам выгрузок. Максимально простая интеграция.
• Mikbill и Abills соответствуют требованиям к форматам выгрузок для СОРМ. Однако необходимо учитывать, что биллинг (автоматизированная система расчетов) должна иметь сертификат по статье «соответствие средств связи», он же – ССС). Если у Mikbill и Abills нет действующих сертификатов, необходимо перейти на другой биллинг.
• Carbon Soft — соответствует требованиям, но в отдельных случаях нужны доработки со стороны поставщика биллинга. Это занимает время и может вызвать дополнительные затраты.