Инсталляция тестовой версии

1. [BRAS] Контроль активности абонента с пом. unicast ARP Request. Ранее был bcast ARP Request, что не оптимально для сети
2. [CLI] Исправлено: help() для IPv6-адресов в команде subs prop show
3. [Router] Исправлено: выбор порта для записи в сквозном LAG. Если LAG проходит сквозь fastDPI, то при выборе порта для записи с TAP нужно учитывать не только состояние самого порта Link Up/Down, но и состояние Link Up/Down второго плеча моста для этого порта
4. [Router] Исправлено: анонсирование подсетей профиля 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 имеют бОльший приоритет, чем записи от bird/FRR.
7. [BRAS][CLI] Исправлена ошибка разбора параметров команды subs prop del, что приводило к невозможности удаления свойств по IP c ошибкой

   ERROR: Result code=9: No subscriber IP address

8. [PCAP] Исправлено: ротация PCAP-файлов при reload

1. [BRAS][DHCP] Добавлена CLI-команда dhcp disconnect. Это CLI-аналог CoA Disconnect. Режим выполнения дисконнекта задается опцией bras_dhcp_disconnect.
   1. dhcp disconnect all - дисконнект всех DHCP-сессий
   2. dhcp disconnect [ mac=X | ip=X ] - дисконнект указанной сессии
2. [BRAS] Исправлено: отправка L3 reauth для L2-абонента заранее, не дожидаясь завершения session timeout
3. [BRAS][DHCP] В CLI-команду dhcp show stat добавлено число закрытых по неактивности сессий (SHCV)
4. [BRAS][DHCP] Добавлено: SHCV - контроль активности DHCP-абонента.
   Реализован алгоритм SHCV (Subscriber Host Connectivity Verification), аналогичный Nokia, - проактивный контроль состояния DHCP-сессии абонента. Если от абонента в течение bras_dhcp_shcv_interval секунд нет никакого трафика, fastdpi начинает пинговать абонента отправкой unicast ARP-запроса от имени абонентского шлюза. Ожидание ответа на ARP-запрос - bras_dhcp_shcv_retry_timeout, секунд. Если на bras_dhcp_shcv_retry_count последовательных ARP-запросов не получено ни одного ответа, либо ARP-ответ содержит другой MAC, абонент считается неактивным, его DHCP-сессия закрывается.
   Новые опции:
   • bras_dhcp_shcv_interval - интервал неактивности, сек;
     0 - SHCV отключен (по умолчанию).
   • bras_dhcp_shcv_retry_timeout - время ожидания ответа на ARP-запрос, сек.
     По умолчанию = 3 секунды.
     
   • bras_dhcp_shcv_retry_count - число ARP-запросов без ответа.
     По умолчанию = 3 запроса.
     
     ''Закрытие DHCP-сессии производится аналогично CoA Disconnect - выполняются действия согласно опции bras_dhcp_disconnect''. Аккаунтинг-сессия закрывается с признаком Acct-Terminate-Cause=4 (Idle timeout), при этом VSA VasExperts-Acct-Terminate-Cause принимает новое значение 20 «Разрыв по неактивности». SHCV реализован на основе API мониторинга активных сессий (груминг ip_db).
     
     Отметим, что в fastdpi уже есть контроль активности абонента, но это реактивный контроль, который осуществляется «по факту», то есть по приходу пакета к абоненту из inet. Если нет трафика из inet к абоненту, - нет и никакого контроля, ARP ping'ов и пр. Такой контроль активности ограничивает входящий трафик к абоненту в случае его неактивности, но не завершает сессию абонента. Новый алгоритм SHCV дополняет такой контроль активным мониторингом открытых DHCP-сессий. Оба алгоритма совместимы и могут работать вместе.
5. [LAG] Исправлено: необнуление массива при построении нового списка активных портов. Ошибка приводит к краху fastDPI (переполнение массива и порча памяти)
6. [Router] Исправлено: не учитывать term by AS при анонсе подсетей NAT. Режим term_by_AS относится к абонентам, а не к профилям NAT, поэтому его не нужно учитывать при анонсировании NAT-подсети

1. [DPI][BRAS] Глобальный рефакторинг кода - отказ от поддержки pf_ring
2. [DPI] Добавлена услуга 19 - подмена dns ответов

   vi test.txt 
   google.com A 1.2.3.4
   example.com A 5.6.7.8
   *.fb.com A 7.8.9.0
   cat test.txt|dns2dic test.bin
   cp test.bin /var/lib/dpi/dns.bin
   fdpi_ctrl load --service 19 --login test
   аналогично на vchannel 

3. Изменен минимальный размер PCAP файла до 100 MB
4. Улучшена трассировка событий DROP
5. [BRAS] Добавлено: ARP Proxy для известных маршрутов (только в режиме роутера). В опцию bras_arp_proxy добавлен новый флаг: 0x0004 - [в режиме роутера] отвечать, если есть путь до запрашиваемого IP. Данный флаг работает только если включен режим роутера. Если абонент запросит ARP для адреса, маршрут для которого нам известен, fastdpi ответит сам своим MAC-адресом bras_arp_mac.

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

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