1. [bras] Контроль активности абонента с пом. unicast ARP Request. Ранее был bcast ARP Request, что не оптимально для сети
2. [cli] fixed: help() для IPv6-адресов в команде `subs prop show`
3. [router] fixed: выбор порта для записи в сквозном LAG. Если LAG проходит сквозь fastdpi, то при выборе порта для записи с TAP нужно учитывать не только состояние самого порта link Up/Down, но и состояние Link Up/Down второго плеча моста для этого порта
4. [router] Fixed: анонсирование подсетей профиля NAT при добавлении
5. [router] Добавлена CLI-команда `router vrf dump` Комаенда выводит список VRF, заданных в системе, и свойства этих VRF.
6. [router] ARP менеджмент

       NeighborDB - это БД nexthop, которую обслуживает сам fastdpi:
       посылает ARP request для выяснения MAC-адреса nexthop, обновляет
       ARP кеш для этих nexthop. Для обновления используются следующие опции:
       - `router_neighbor_lifetime` - время жизни записи в ARP кеше, в секундах.
         По истечении этого времени запись нужно обновить отправкой ARP request
         (ICMPv6 NDP в случае IPv6). Значение по умолдчанию: 300 секунд
       - `router_neighbor_refresh_timeout` - сколько секунд ждем ответа на
          ARP request. Значение по умолчанию: 3 секунды
       - `router_neighbor_refresh_attempt` - сколько безуспешных попыток
          обновления нужно для того, чтобы перевести запись ARP-кеша в сотсоянии
          Unreachable (недостижимая); другими словами, сколько подряд надо послать
          ARP Request без ответа, чтобы запись стала unreachable.
          Значение по умолчанию: 10 попыток
       - `router_neighbor_unreachable_refresh` - после того, как запись
          становится Unreachable, fastdpi периодически пытается оживить её,
          посылая ARP Request. Данная опция задает этот период в секундах
          (по умолчанию 30 сек).
   
       Запись nexthop состоит из:
       - собственно nexthop IP
       - [обязательно] имя порта , через который осуществляется связь с этим nexthop
         (в случае LAG - один из портов, входящих в LAG)
       - [опционально] VLAN
       - [опционально] MAC-адрес nexthop. Записи с явно заданным MAC-адресом nexthop
         являются static ARP cache record - по ним никогда не посылается ARP-запросов
       IPv4 и IPv6 NeighborDB хранится в SDR в файле `router.mdb`.
       SDR (System Data Repository) - это новая сущность наподобие UDR, но содержащая
       системные настройки. Каталог, где располагается SDR, задается новой опцией
       `sdr_path`, по умолчанию это `/var/db/dpisdr`.
   
       Управление NeighborDB - добавление/модификация/удаление записей - производится
       через команды CLI:
       - `router neighbor dump` - выводит полный список всех загруженных записей и их
          внутреннее состояние
       - `router neighbor dump db` - выводит дамп БД router.mdb.
       - `router neighbor add` - добавление новой записи (нового nexthop) в NeighborDB.
       - `router neighbor update` - модификация существующей записи NeighborDB
       - `router neighbor delete` - удаление записи NeighborDB
       - `router neighbor refresh` - принудительное обновление (отправка ARP Request)
          MAC-адреса конкретного nexthop IP, или всех nexthop в указанном VRF, или
          всей NeighborDB
       - `router neighbor purge` - удаление всех записей NeighborDB, то есть полная
          очистка NeighborDB.
       Синтаксис каждой из этих команд см. `fdpi_cli <command> ?`
   
       Приоритетность в ARP кеше
       С появлением NeighborDB в fastdpi появляются два независимых источника записей
       в ARP кеше:
       - [прежний] bird/FRR: fastdpi отлавливает взаимодействие bird/FRR с соседями и
         соотвественно заполняет свой ARP кеш для nexthop; fastdpi не обновляет статус
         таких записей отправкой ARP Request, а надеется на то, что это сделает bird/FRR
       - [новый] NeighborDB: fastdpi сам следит за актуальностью записей, своевременно
         отправляя ARP Request.
       *Записи NeighborDB имеют бОльший приоритет*, чем записи от bidr/FRR.

7. [bras][cli] Fixed ошибка разбора параметров команды `subs prop del` что приводило к невозможности удаления свойств по IP c ошибкой ERROR: Result code=9: No subscriber IP address
8. [pcap] Fixed: ротация pcap-файлов при reload

1. [bras][dhcp] Добавлена CLI-команда `dhcp disconnect` Это CLI-аналог CoA Disconnect. Режим выполнения дисконнекта задается опцией `bras_dhcp_disconnect`. `dhcp disconnect all` - дисконнект всех DHCP-сессий `dhcp disconnect [ mac=X | ip=X ]` - дисконнект указанной сессии
2. [bras] Fixed: отправка L3 reauth для L2-абонента заранее, не дожидаясь завершения session timeout
3. [bras][dhcp] В CLI-команду `dhcp show stat`добавлено число закрытых по неактивности сессий (SHCV)
4. [bras][dhcp] Добавлено: SHCV - контроль активности DHCP-абонента

       Реализован алгоритм SHCV (Subscriber Host Connectivity Verification),  аналогичный Nokia (https://documentation.nokia.com/html/0_add-h-f/93-0267-HTML/7X50_Advanced_Configuration_Guide/dhcp-hosts.html#433540), - проактивный контроль состояния DHCP-сессии абонента.
       Если от абонента в течение` bras_dhcp_shcv_interval` секунд нет никакого трафика,  fastdpi начинает пинговать абонента отправкой unicast ARP-запроса от имени абонентского шлюза. Ожидание ответа на ARP-запрос - `bras_dhcp_shcv_retry_timeout`, секунд.
       Если на `bras_dhcp_shcv_retry_count` последовательных ARP-запросов не получено ни одного ответа, либо ARP-ответ содержит другой MAC, абонент считается неактивным, его DHCP-сессия закрывается.
   
       Новые опции:
       -  Интервал неактивности, секунд; 0 - SHCV отключен.
           `bras_dhcp_shcv_interval=0`
       -  Время ожидания ответа на ARP-запрос, секунд, по умолчанию = 3 секунды.
           `bras_dhcp_shcv_retry_timeout=3`
       -  Число ARP-запросов без ответа, по умолчанию = 3.
          `bras_dhcp_shcv_retry_count=3`
   
       Закрытие DHCP-сессии производится аналогично CoA Disconnect - выполняются действия согласно опции `bras_dhcp_disconnect`.
       Аккаунтинг-сессия закрывается с признаком `Acct-Terminate-Cause=4` (Idle timeout), при этом VSA `VasExperts-Acct-Terminate-Cause` принимает новое значение 20 "Разрыв по неактивности".
   
       SHCV реализован на основе API мониторинга активных сессий (груминг ip_db).
   
       Отметим, что в fastdpi уже есть контроль активности абонента, см. https://wiki.vasexperts.ru/doku.php?id=dpi:bras_bng:bras_l2_options:subs_activity:start.
       Но это реактивный контроль, который осуществляется "по факту", то есть по приходу пакета к абоненту из inet. Если нет трафика из inet к абоненту, - нет и никакого контроля, ARP ping'ов и пр. Такой контроль активности ограничивает входящий трафик к абоненту в случае его неактивности, но не завершает сессию абонента.
       Новый алгоритм SHCV дополняет такой контроль активным мониторингом открытых DHCP-сессий. Оба алгоритма совместимы и могут работать вместе.

5. [lag] Fixed: необнуление массива при построении нового списка активных портов. Ошибка приводит к краху fastdpi (переполнение массива и порча памяти)
6. [router] Fixed: не учитывать term by AS при анонсе подсетей NAT. Режим term_by_AS относится к абонентам, а не к профилям NAT, поэтому его не нужно учитывать при анонсировании NAT-подсети

Проверить текущую установленную версию можно командой

yum info fastdpi

Если у вас установлена версия CentOS 6.x или CentOS 8.x, то однократно переключите репозиторий командой:

sed -i -e '/^mirrorlist=http:\/\//d' -e 's/^# *baseurl=http:\/\/mirror.centos.org/baseurl=http:\/\/vault.centos.org/' /etc/yum.repos.d/CentOS-*.repo

и далее производите обновления как обычно.

Команда установки тестовой версии:

yum --enablerepo vasexperts-beta update fastdpi

Откат на 13.0:

yum downgrade fastdpi-13.0 fastpcrf-13.0