Резервирование BRAS в режиме L2 предполагает включение двух СКАТ в один широковещательный L2 домен. Один в режиме Master, другой в режиме Slave. Master осуществляет обработку трафика, авторизацию пользователей через PCRF сервер. Slave не пропускает трафик через себя, интерфейсы DPDK находятся в режиме ожидания трафика (down). Синхронизация информации об абонентах происходит через PCRF сервер. Slave отслеживает доступность и работоспособность Master, при сбое в работе Slave в автоматическом или ручном режиме активирует (up) DPDK интерфейсы и начинает обрабатывать трафик. Пример включения и прохождения трафика представлено на схеме.

В СКАТ BRAS состоит из компонент

• fastDPI - обработка трафика абонентов.
• fastPCRF - интеграция по протоколу Radius между fastDPI и Radius сервером. Один fastPCRF может обслуживать несколько fastDPI серверов.

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

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

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

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

Концепция резервирования СКАТ — MASTER-SLAVE:
MASTER является активным сервером и обрабатывает трафик во время нормальной работы сети. SLAVE в свою очередь находится в состоянии ожидания с выключенными интерфейсами и активно опрашивает состояние MASTER и в случае проблем на нем включается в работу.

Нормальная работа сети:
Через MASTER проходит обработка всего трафика, авторизация и т.д, SLAVE в обработке трафика не участвует, но через mgmt интерфейс опрашивает состояние MASTER. Происходит несколько проверок состояния:

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

Если все проверки прошли успешно, то SLAVE остается в режиме ожидания и не предпринимает никаких действий.
В случае обнаружения ошибки SLAVE берет на себя роль MASTER.

Переключение MASTER→SLAVE:
При обнаружении на MASTER ошибки SLAVE начинает обрабатывать трафик самостоятельно, для этого отправляется команда на отключение MASTER, отключение интерфейсов СКАТ и остановки процесса fastDPI. В это же время SLAVE включает свои интерфейсы. Следует отметить, что автоматического переключения обратно не реализовано, так как необходима проверка инженером что проблема на основном сервере устранена и можно переключать траффик обратно.

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

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

1. Сервер доступен по сети (pingcheck)
2. Процесс fastDPI присутствует
3. PID процесса fastDPI не изменился (нет неконтролируемого перезапуска процесса)
4. Состояние ссылки на основном fastDPI не изменилось (необязательная проверка). Эта проверка отключена по умолчанию, так как может быть не нужна в некоторых топологиях.

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

1. Скачать все файлы из архива на целевой резервный сервер.
2. Настроить IP-адрес основного сервера в скрипте SRS.sh.
3. Создать пару SSH-ключей на резервном сервере с помощью команды

   ssh-keygen -t ed25519

4. Создать нового пользователя с правами sudo на основном сервере.
5. Скопировать приватные SSH-ключи с резервного сервера в файл authorized_keys нового аккаунта на основном сервере.
6. Добавить права на выполнение установочного скрипта с помощью команды

   chmod +x install.sh

7. Запустить install.sh.

Управление сервисом:

1. Запуск сервиса:

   systemctl start fastsrs

2. Проверка статуса сервиса:

   systemctl status fastsrs

3. Остановка сервиса:

   systemctl stop fastsrs

4. Проверка логов сервиса:

   journalctl -u fastsrs

Скрипт синхронизирует профили услуг 4 (фильтрация по черному списку), 5 (белый список и Captive Portal), 18 (полисинг по сессии и переопределение классов трафика) и полисинга между двумя DPI.
Скрипт запускается на основном DPI, профили услуг на удаленном DPI будут приведены к виду профилей на основном DPI. Перенос профилей осуществляется с помощью команд fdpi_ctrl и удаленного доступа по ssh.

Требования к системе:

• Ssh
• Bash
• Jq
• СКАТ DPI
• Rsync

Логика работы скрипта:
Скрипт получает текущий профиль услуги от главного устройства и затем отправляет его на указанный удаленный DPI. Затем скрипт подключается к удаленному DPI и получает данные для профилей, присутствующих на удаленном DPI, получает данные профиля на текущем DPI, сопоставляет их и удаляет профили, отсутствующие на основном DPI.

1. Настроить авторизацию через сертификат: создать сертификат на главном сервере с помощью ssh-keygen -t ed25519, проще всего использовать для авторизации учетную запись root.
2. Загрузить скрипт на главный сервер и поместить его в каталог /usr/local/bin/
3. Добавить разрешения для скрипта с помощью команды

   chmod +x /usr/local/bin/profile_sync.sh

4. Настроить пользователя и IP удаленного сервера внутри скрипта. Пользователь должен иметь возможность записи в каталог /etc/dpi, самый простой вариант — использовать пользователя root. Также можно настроить другого пользователя с соответствующими правами.
5. Настроить cron для выполнения скрипта с желаемыми интервалами (опционально):

   crontab -u root -e
   0 * * * * * /bin/bash /usr/local/bin/profile_sync.sh

6. Добавить псевдоним bash для запуска скрипта по желанию:

   echo "alias dpi_sync='/bin/bash /usr/local/bin/profile_sync.sh'">> ~/.bashrc

7. Создать каталог /etc/dpi/service18 и сохранить в нем все файлы service 18.

Работа скрипта:
Скрипт запускается crontab с указанными интервалами или вручную с помощью команды dpi_sync.

Обратите внимание, что если профиль сервиса применен к абоненту, он не будет удален. Также обратите внимание, что любые файлы, не сохраненные в папке service18, не будут перенесены на удаленный DPI, и, таким образом, синхронизированный профиль услуги 18 не будет работать. При отсутствии alias dpi_sync cкрипт следует запускать через sudo bash /usr/local/bin/profile_sync.sh.