| Предыдущая версия справа и слеваПредыдущая версияСледующая версия | Предыдущая версия |
| dpi:dpi_components:pcrf [2024/09/26 15:29] – внешнее изменение 127.0.0.1 | dpi:dpi_components:pcrf [2025/09/13 06:25] (текущий) – atereschenko |
|---|
| Адрес сервера - ''1.1.1.1'' там, где установлен модуль ''fastDPI''.\\ | Адрес сервера - ''1.1.1.1'' там, где установлен модуль ''fastDPI''.\\ |
| Адрес сервера - ''2.2.2.2'' там, где установлен модуль ''fastPCRF''. | Адрес сервера - ''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.__ |
| |
