====== FastPCRF (интеграция BRAS по RADIUS) ======
{{indexmenu_n>2}}

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

Для подсистемы можно использовать оборудование или виртуальные машины со следующими характеристиками:
  - Процессор (CPU) 2.5 ГГц, 1 шт
  - Оперативная память (RAM) 512 Мб - 1 Гб
  - Жесткий диск (HDD) 50 Гб - 250 Гб
  - Операционная система CentOS 8.5, [[veos:installation|VEOS]]
  - Сетевая плата (NIC) от 10 Mб/сек

===== Установка =====
  - Установите службу точного времени<code>yum install chrony -y
systemctl restart chronyd
timedatectl</code> :!: При вводе команды ''timedatectl'', у параметра ''System clock synchronized'' должно быть значение ''yes''
  - Подключите репозиторий vasexperts <code>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</code>
  - Установите fastPCRF <code>yum install fastpcrf</code>
  - Проверьте что сервис запускается <code>service fastpcrf start</code>
  - Включите автозапуск сервиса при старте компьютера<code>systemctl enable fastpcrf</code>
  - Откройте порты на firewall для доступа к fastPCRF и Radius серверу<code>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
</code>
и загрузите новые правила 
<code>firewall-cmd --reload</code>
  - Отключите selinux ((временное решение))<code>setenforce 0
vi /etc/selinux/config
SELINUX=disabled</code>
 

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

Данные утилиты можно взять с сервера, где установлен ''fastDPI''.\\
Файлы утилит находятся в ''/usr/sbin/''.
  - Копируем утилиты в домашнюю директорию <code>
cp /usr/sbin/fdpi_cli /home/vasexpertsmnt
cp /usr/sbin/fdpi_ctrl /home/vasexpertsmnt
</code>
  - Переносим данные файлы на сервер, где установлен ''fastPCRF'' в ''/home/vasexpertsmnt''

Как использовать утилиту:\\
<code>
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
</code>
Адрес сервера - ''1.1.1.1'' там, где установлен модуль ''fastDPI''.\\
Адрес сервера - ''2.2.2.2'' там, где установлен модуль ''fastPCRF''.

===== Репликация данных авторизации и Синхронизация базы данных нескольких СКАТ BRAS =====
<note>Вебинар по теме:
{{youtube>wCkuTfqoKQc?}}</note>
В СКАТ BRAS состоит из двух компонентов:
  * fastDPI - обработка трафика абонентов.
  * fastPCRF - интеграция по протоколу Radius между fastDPI и Radius сервером. Один fastPCRF может обслуживать несколько fastDPI серверов.
Возможны две схемы интеграции:
  - Два fastDPI и один вынесенный fastPCRF  - есть возможность синхронизировать данные UDR двух fastDPI. Описание представлено ниже.
  - На каждом сервере fastDPI свой fastPCRF - нет возможности синхронизировать данные UDR двух fastDPI, после переключения идет наполнение UDR из ответов от RADIUS сервера. Описание в статье: [[dpi:bras_bng:replication|]]

Пример включения и прохождения трафика для вынесенного fastPCRF представлено на схеме. {{ :dpi:bras_bng:replication:bras_l2_reservation.png?nolink&750 |}}

Для первого варианта применяется следующая схема репликации для согласования данных об абонентах на всех fastDPI-серверах: fastPCRF шлет ответы авторизации и CoA-запросы на все fastDPI серверы, перечисленные в параметрах [[dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup|fdpi_server]]. 
<note important>Отправка параметров авторизации производится через персистентную очередь, так что даже если какой-то из серверов fastDPI был отключен на момент отправки данных, при включении он получит все данные за время своего простоя.</note>

==== Применение данных на 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.__