Soft-Router — это функция маршрутизации в СКАТ, которая строит и поддерживает собственную таблицу маршрутизации. Функция реализована поверх стандартных механизмов Linux (kernel route table, network namespace) и стороннего роут-демона (BIRD, FRR и др.), который обрабатывает протоколы динамической маршрутизации, а СКАТ использует построенную им таблицу для маршрутизации трафика абонентов. Помимо базовой маршрутизации, Soft-Router поддерживает VRF Lite — изоляцию таблиц маршрутизации для разных групп абонентов или сервисов в рамках одного устройства.

Сам СКАТ не занимается построением таблицы маршрутизации. Он делегирует эту работу проверенным специализированным инструментам, в примере внутренней архитектуры роутера использован роут-демон BIRD. Роут-демон обрабатывает требуемые протоколы маршрутизации (BGP, OSPF и пр.) и по ним строит общую таблицу маршрутизации, которую загружает в ядро операционной системы. СКАТ по этой таблице осуществляет маршрутизацию пакетов. Т.е. разделяется процесс построения таблицы и обработки трафика согласно таблицы маршрутизации.

Так как BIRD строит таблицу маршрутизации в ядре ОС, то во избежание применения этих правил самим Linux-сервером роут-демон BIRD работает в отдельном net namespace (на схеме внутренней архитектуры роутера это router netns). Пакеты протоколов маршрутизации поступают на in/out-девайсы СКАТа в общем трафике. Для каждого in/out-девайса, участвующего в маршрутизации, создается veth-пара «теневых» интерфейсов: TAP-интерфейс на стороне СКАТ (например, bng-w) и парный интерфейс (например, rib-w) — обычный системный интерфейс в netns роут-демона.

Системные требования описаны в разделе Требования к оборудованию и производительность.

Данные из kernel route table вычитываются (rtnetlink) в RIB (Routing Information Base) роутера. RIB — это префиксное дерево, его удобно модифицировать по событиям изменения (удаления/добавления записей) route table ядра. С RIB работает отдельный поток роутера, т.к. RIB не поддерживает многопоточный доступ.

Процесс синхронизации выполняется как минимум в два прохода: синхронизация считается успешной, если два последовательных чтения Linux route table вернули одинаковое число записей. FastDPI будет вычитывать route table до тех пор, пока это условие не выполнится, но при этом если 4 попытки подряд оказались неудачными, то fastDPI строит свой RIB/FIB по последней попытке и планирует новую синхронизацию через небольшое время (2 секунды).

Рабочие потоки fastDPI используют FIB (Forwarding Information Base). Эта структура заточена на многопоточный поиск (LPM — longest prefix match), но не предназначена для модификаций (удаления/добавления новых записей). FIB можно только построить с нуля по RIB и затем использовать для LPM. Поэтому в СКАТ существуют два FIB — текущая (которая сейчас используется для роутинга рабочими потоками) и "будущая". СКАТ раз в router_fib_refresh секунд проверяет, не было ли изменений в RIB с момента построения текущей FIB. Если изменения были, СКАТ строит (в потоке роутера) новую FIB на месте "будущей", а затем сразу переключает текущую FIB на новую. Тем самым рабочие потоки увидят все изменения, которые произошли в таблице маршрутизации.

Настройки Роут-демона (BIRD, FRR, etc.) и СКАТ должны быть согласованы: роут-демон должен создавать kernel route table с номером, задаваемым параметром router_kernel_table.

Поддерживаемые роут-демоны:

1. BIRD. Поддерживается BIRD версии 2 и выше. Версия 1 не поддерживается.
   Пример конфигурации
   Официальная документация
2. FRRouting
   Официальная документация
3. QUAGGA
   Официальная документация
4. Juniper CRPD
   Официальная документация

Роутер поддерживает работу с агрегированными каналами (LAG).

Для агрегированных каналов пакеты, которые нужно отводить на TAP-интерфейс, могут прийти на любой девайс, входящий в LAG. Чтобы не создавать фактически одинаковые TAP-интерфейсы для каждого девайса из LAG, роутер учитывает, какие девайсы входят в LAG и для всех таких девайсов делает отвод трафика указанных подсетей на TAP (к демону BIRD).

Каждый LAG задается отдельной секцией в fastdpi.conf, в которой перечисляются все девайсы, входящие в LAG. Рекомендуется использовать активный LAG (с LACP); «прозрачный» LAG без LACP используйте только для резервирования СКАТ там, где это допустимо (например, при фильтрации). Пример активного LAG в сторону inet:

in_dev=01-00.0:02-00.0
out_dev=01-00.1:02-00.1

lag {
    name=inet
    lacp=2
    short_timeout=on
    device=01-00.1
    device=02-00.1
}

router_device {
    device=01-00.1
    tap=bng-w
    peer=rib-w
    subnet=10.0.10.0/26
}

Где:

• in_dev, out_dev — входные и выходные девайсы, которые объединяются в LAG.
• lag — описание LAG в сторону inet:
  • name — необязательное имя LAG, используется только для вывода в лог;
  • lacp — режим обработки LACP:
    • 0 — обработка LACP отключена: СКАТ не держит LAG, а «прозрачно» пропускает трафик (значение по умолчанию);
    • 1 — пассивный режим: СКАТ не шлёт периодические LACPDU, но отвечает на пришедшие;
    • 2 — активный режим: СКАТ периодически шлёт LACPDU. Рекомендуемое значение, используется в примере;
  • short_timeout — таймаут LACP: on — короткий, off — длинный;
  • device — девайс, входящий в LAG. Каждый девайс задаётся отдельным параметром device.
• router_device — описание интерфейса роутера:
  • device — имя девайса из out_dev. Veth-пару TAP-интерфейсов создаём только для этого девайса, а не для каждого девайса из LAG;
  • tap — имя TAP-интерфейса для девайса. По умолчанию — dpi + имя девайса;
  • peer — имя парного TAP-интерфейса в netns. По умолчанию — rib + имя девайса;
  • subnet — подсеть, которая отводится из общего трафика на TAP-интерфейс. Если подсетей несколько, каждая задаётся отдельным параметром subnet.

Если роутер работает и в сторону inet, и в сторону subs (например, BGP на стороне inet и OSPF в сторону subs), для LAG каждого направления задаётся своя секция router_device. Подробно настройка активного LAG описана в разделе Настройка on-stick и LAG/LACP.

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-запросы.

NeighborDB (IPv4 и IPv6) хранится в 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).

С появлением NeighborDB в fastDPI появились два независимых источника записей в ARP кеше:

• [прежний] сетевой стек ОС в netns. fastDPI отлавливает взаимодействие с соседями и соответственно заполняет свой ARP кеш для nexthop. Источником ARP запросов является SoftRouter или любой другой сервис, который запрашивает данные о соседях.
• [новый] NeighborDB: fastDPI сам следит за актуальностью записей, своевременно отправляя ARP Request. Записи NeighborDB имеют больший приоритет, чем записи от BIRD/FRR.

Включение анонсирования адресов абонентов производится параметром в fastdpi.conf:

router_subs_announce=6

Параметр является битовой маской. Значения:

• 0x00001 — анонсировать адрес абонента в сторону subs
• 0x00002 — анонсировать адрес абонента в сторону inet (если у абонента не подключен NAT)
• 0x00004 — анонсировать NAT-подсети в сторону inet
• 0x00008 — анонсировать абонентские шлюзы (направление задается флагами 1 и 2)
• 0x10000 — деанонсировать L3-абонента при наступлении acct idle (закрытие acct-сессии по idle timeout)

Значение по умолчанию: 0 — ничего никуда не анонсировать

Флаги складываются. Возможные значения router_subs_announce:

Чтобы дополнительно деанонсировать L3-абонента при закрытии acct-сессии по idle timeout, добавьте к значению из таблицы флаг 0x10000 (65536). Например, router_subs_announce=0x10006 (65542) — анонсировать адрес абонента и NAT-подсети в сторону inet и деанонсировать абонента по idle timeout. Значения 0x10000, 0x10008 и 0x1000c не используются.

Подсети белых адресов NAT анонсируются только в сторону inet при старте СКАТа и при добавлении/удалении/изменении NAT-профилей.

Адреса абонентов могут анонсироваться как в сторону inet, так и в сторону subs. Но если IP-адрес абонента входит в диапазон приватных адресов и на него назначена 11 услуга, адрес абонента не анонсируется в сторону inet, поэтому нужно с осторожностью определять диапазоны приватных адресов.

Анонс производится в таблицу маршрутизации BIRD для всех TAP-девайсов разрешенного направления, далее BIRD подхватывает изменения и анонсирует их по нужным протоколам в соответствии со своей конфигурацией.

Если в fastdpi.conf задано nat_exclude_private=1, то есть не применять NAT для пакетов "приватный IP → приватный IP", то СКАТ будет анонсировать приватный адрес абонента с подключенным NAT в сторону inet, так как вышестоящий роутер должен знать маршрут до серого IP-адреса абонента.

Алгоритм анонсов IP-адресов L3-абонентов:

• по умолчанию, анонс адреса производится для успешной авторизации (accept) и НЕ производится для неуспешной (reject)
• fastdpi.conf-параметр auth_announce_reject позволяет глобально разрешить анонсы для reject. Возможные значения:
  • 1 — анонсировать неавторизованных (Reject) абонентов
  • 0 — не анонсировать неавторизованных (Reject) абонентов (значение по умолчанию)
• RADIUS-атрибут VasExperts-Route-Announce: значение 0 — не анонсировать адрес абонента, значение 1 — анонсировать. Данный атрибут имеет более высокий приоритет, чем auth_announce_reject.

Итого при решении вопроса, нужно ли анонсировать IP-адрес абонента или нет, применяется следующий алгоритм:

• если в ответе RADIUS (Accept или Reject) явно задан атрибут VasExperts-Route-Announce, анонс будет производиться для VasExperts-Route-Announce=1 и НЕ будет для VasExperts-Route-Announce=0
• если атрибута VasExperts-Route-Announce в ответе RADIUS нет:
  • Для Access-Accept (успешная авторизация) IP-адрес абонента анонсируется
  • Для Access-Reject (неуспешная авторизация) IP-адрес анонсируется только если fastdpi.conf-параметр auth_announce_reject=1

Данный алгоритм также применяется для ARP-авторизации и GTP-авторизации, то есть для всех типов авторизации, где IP-адрес абонента известен на момент вызова авторизации и не может быть изменен.

Для прочих видов L2-авторизации (DHCP, PPP, — всех, где явно выдается IP-адрес) атрибут VasExperts-Route-Announce не принимается в расчет, анонс происходит по факту выдачи IP-адреса абоненту.

СКАТ поддерживает Equal-cost multi-path routing (ECMP).

СКАТ балансирует трафик (round-robin) на уровне flow по всем маршрутам из multi-path. Балансировка на уровне flow означает, что конкретный flow закрепляется за одним из маршрутов multi-path, и выбранный маршрут не меняется до окончания flow (если состав multi-path не изменится по внешним событиям от демона маршрутизации).

При отправке трафика по выбранному маршруту СКАТ использует tx-девайс, относящийся к этому маршруту.

Для работы на серверах с двумя CPU при выборе маршрута из multi-path СКАТ может учитывать NUMA-топологию системы. Для этого должны выполняться два условия:

• в fastdpi.conf задан параметр numa=on;
• в системе больше одной NUMA-ноды (число NUMA-нод определяется DPDK при инициализации).

В этом случае приоритет отдается маршруту через tx-девайс, который относится к той же NUMA-ноде, что и rx-порт, на который пришел пакет. Если такого маршрута в multi-path нет, маршрут выбирается без учета NUMA.

Для включения multi-path в СКАТ не требуется никакой настройки. Поддержка ECMP включается в конфигурационных параметрах демона маршрутизации. Например, в BIRD поддержка ECMP включается указанием merge paths yes в протоколе kernel, см. документацию BIRD.