Содержание

FastPCRF (интеграция BRAS по RADIUS)

Обеспечивает проксирование запросов от fastDPI в сторону Radius сервера. Входит в стандартный пакет установки СКАТ DPI, но при необходимости может быть вынесен на отдельный сервер.

Рекомендации к оборудованию

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

  1. Процессор (CPU) 2.5 ГГц, 1 шт
  2. Оперативная память (RAM) 512 Мб - 1 Гб
  3. Жесткий диск (HDD) 50 Гб - 250 Гб
  4. Операционная система CentOS 8.5, VEOS
  5. Сетевая плата (NIC) от 10 Mб/сек

Установка

  1. Установите службу точного времени
    yum install chrony -y
systemctl restart chronyd
timedatectl

    :!: При вводе команды timedatectl, у параметра System clock synchronized должно быть значение yes

  2. Подключите репозиторий vasexperts 
    rpm --import http://vasexperts.ru/centos/RPM-GPG-KEY-vasexperts.ru
rpm -Uvh http://vasexperts.ru/centos/6/x86_64/vasexperts-repo-2-1.noarch.rpm
  3. Установите fastPCRF 
    yum install fastpcrf
  4. Проверьте что сервис запускается 
    service fastpcrf start
  5. Включите автозапуск сервиса при старте компьютера
    systemctl enable fastpcrf
  6. Откройте порты на firewall для доступа к fastPCRF и Radius серверу
    firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=3799/udp
firewall-cmd --permanent --zone=public --add-port=29002/tcp

и загрузите новые правила 

firewall-cmd --reload
  1. Отключите selinux 1)
    setenforce 0
vi /etc/selinux/config
SELINUX=disabled

Установка утилит fdpi_cli и fdpi_ctrl на сервер PCRF

Данные утилиты можно взять с сервера, где установлен fastDPI.
Файлы утилит находятся в /usr/sbin/.

  1. Копируем утилиты в домашнюю директорию 
    cp /usr/sbin/fdpi_cli /home/vasexpertsmnt
cp /usr/sbin/fdpi_ctrl /home/vasexpertsmnt
  2. Переносим данные файлы на сервер, где установлен fastPCRF в /home/vasexpertsmnt

Как использовать утилиту:

fdpi_cli -r 1.1.1.1 dpi config get trace_ip 
fdpi_cli -r 2.2.2.2 pcrf config get verbose
fdpi_ctrl -r 1.1.1.1:29000 list all --bind

Адрес сервера - 1.1.1.1 там, где установлен модуль fastDPI.
Адрес сервера - 2.2.2.2 там, где установлен модуль fastPCRF.

Репликация данных авторизации и Синхронизация базы данных нескольких СКАТ BRAS

Вебинар по теме:

В СКАТ BRAS состоит из двух компонентов:

Возможны две схемы интеграции:

  1. Два fastDPI и один вынесенный fastPCRF - есть возможность синхронизировать данные UDR двух fastDPI. Описание представлено ниже.
  2. На каждом сервере fastDPI свой fastPCRF - нет возможности синхронизировать данные UDR двух fastDPI, после переключения идет наполнение UDR из ответов от RADIUS сервера. Описание в статье: Резервирование BRAS Active-Standby

Пример включения и прохождения трафика для вынесенного fastPCRF представлено на схеме.

Для первого варианта применяется следующая схема репликации для согласования данных об абонентах на всех fastDPI-серверах: fastPCRF шлет ответы авторизации и CoA-запросы на все fastDPI серверы, перечисленные в параметрах fdpi_server.

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

Применение данных на fastDPI при синхронизации UDR

При приеме данных авторизации сервер fastDPI видит, его это был запрос или же это ответ на чужой запрос (для этого в пакете есть специальная метка). Если это ответ на свой запрос, данные применяются "по полной": создается DHCP или PPPoE-сессия, если это был запрос DHCP или PPPoE-авторизации, данные запоминаются в UDR. Если же это ответ на чужой запрос, fastDPI просто запоминает "чужие" данные у себя в UDR. Тем самым при отключении основного fastDPI-сервера и переводе нагрузки на резервный, у резервного fastDPI-сервера в UDR уже будут все свойства абонента - его услуги, полисинг, L2-свойства - MAC-адрес, VLAN и пр. То есть UDR у основного и резервного серверов будут по большому счету согласованы. Абонентская сессия на резервном fastDPI будет в статусе неизвестен (unknown) и после переключения трафика по первому пакету будет запущен процесс авторизации абонента. Тем самым данный вариант синхронизации данных помогает ускорить процесс выхода абонентов в интернет, но только в тех конфигурациях, где IP адрес уже назначен статически на клиенте или же выдается самим биллингом через атрибут Framed-IP. Данный метод не подходит для абонентов DHCP с выдачей IP из локального DHCP сервера на BRAS, который определяется через атрибут Framed-Pool.

1)
временное решение