tspu-docs/chapters/04.md

4. Балансировщик (EcoFilter Balancer)

← Оглавление · ← Раздел 3: Байпас

---

4.1. Назначение: распределение трафика по фильтрам

Балансировщик (EcoFilter Balancer) — это высокопроизводительный программируемый коммутатор, основная задача которого — принимать трафик от байпасов и равномерно распределять его по подключённым фильтрам для анализа и обработки.

Помимо балансировки, балансировщик выполняет следующие функции:

• фильтрация служебного трафика — байпас (прозрачный пропуск) трафика, который не нужно отправлять на фильтры;
• программный байпас — возможность заворачивать трафик обратно к оператору, минуя фильтры;
• контроль доступности фильтров — отправка keep-alive пакетов и автоматическое отключение неисправных фильтров;
• прозрачный пропуск heartbeat-пакетов байпаса Silicom между своими портами.

Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. По умолчанию балансировщик поставляется без конфигурации — все порты, линки и правила необходимо создавать вручную при проектировании конкретного узла.

4.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с

Балансировщик представляет собой компактное одноюнитовое (1U) устройство:

Параметр	Значение
Форм-фактор	1U (одноюнитовый)
Количество портов	32 порта QSFP28
Пропускная способность	3.2 Тбит/с (на пакетах > 160 байт)
Скорости портов	10G / 25G / 100G
Питание	2 блока питания, горячее резервирование
Передняя панель	Консоль, Management Ethernet (1G), USB

Существуют также двухюнитовые балансировщики (65 портов), но в проекте АСБИ используются только одноюнитовые модели.

Для подключения 10-гигабитных интерфейсов используются гидры (breakout-кабели): один порт QSFP28 разветвляется на четыре порта SFP+ (10G) с помощью оптических или DAC-кабелей. Таким образом, один физический QSFP28-порт может предоставить до четырёх 10G-портов.

При работе на скорости 100G все четыре линии (lane) физического порта объединяются и работают совместно.

4.3. Организация портов: пары LAN/WAN, линки

Все порты балансировщика логически делятся на две группы:

• Порты в сторону оператора (через байпасы) — подключены к каналам связи оператора;
• Порты в сторону фильтров — подключены к фильтрам для передачи трафика на обработку.

Порты внутри каждой группы объединяются в пары LAN + WAN и далее — в логические сущности, называемые линками.

    Оборудование оператора (через байпасы)
          │           │           │           │
        P42(L)     P41(W)     P10(L)     P9(W)
          └─────┬─────┘           └─────┬─────┘
             Линк 1               Линк 2
              (10G)               (100G)
                │                     │
    ┌───────────┴─────────────────────┴──────────┐
    │               Балансировщик                │
    │                                            │
    │        Flow rules → Balance Group          │
    └───┬─────┬─────┬──────────┬─────┬─────┬─────┘
      P21(L) P22(W) P31(L) P32(W) P41(L) P42(W)
        └──┬──┘       └──┬──┘       └──┬──┘
      Filter Group 1  Filter Group 2  Filter Group 3
           │               │               │
        Фильтр 1       Фильтр 2       Фильтр N

4.3.1. Принцип чётных/нечётных портов

По договорённости, принятой при проектировании, на балансировщике соблюдается тот же принцип, что и на фильтрах:

• Чётные порты — LAN (в сторону абонентов);
• Нечётные порты — WAN (в сторону интернета).

Например: порт P42 (чётный) — LAN-порт, парный ему P41 (нечётный) — WAN-порт. Для 100-гигабитных портов, у которых нет второй цифры (номера линии), определяющей является единственная цифра: P10 (чётный) — LAN, P9 (нечётный) — WAN.

Этот принцип распространяется как на порты в сторону операторского оборудования, так и на порты в сторону фильтров.

4.3.2. Жёсткая привязка: трафик возвращается в тот же линк

Трафик, пришедший через конкретный порт оператора, обязательно возвращается через парный порт того же линка. Пакет, вошедший через P42 (LAN), после обработки выйдет только через P41 (WAN) — и никуда больше. Аналогично, пакет из P41 вернётся только в P42.

Это фундаментальное правило обеспечивает прозрачность ТСПУ для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его обратно в тот же канал, независимо от того, каким фильтром пакет был обработан.

Механизм реализации: при балансировке к пакету добавляется 4-байтовый заголовок, который, помимо информации о ядре фильтра, содержит идентификатор исходного линка. Когда фильтр возвращает обработанный пакет с этим заголовком, балансировщик по нему определяет, в какой операторский линк вернуть пакет.

4.4. Фильтры на балансировщике (Flow rules)

Перед отправкой трафика на фильтры балансировщик пропускает каждый пакет через правила фильтрации (flow rules). Каждое правило состоит из двух частей:

• Match — условие совпадения (по каким критериям определять трафик);
• Action — действие (что делать с совпавшим трафиком).

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

4.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация)

Действие action bypass позволяет указать, что совпавший трафик должен быть немедленно возвращён в сторону оператора, минуя фильтры. Это используется для служебного трафика:

• BGP (TCP-порт 179) — протоколы маршрутизации;
• Мультикаст-трафик — групповые рассылки;
• Другие служебные протоколы, которые нежелательно пропускать через DPI.

С таким трафиком на фильтрах ничего плохого не произойдёт (он будет прозрачно пропущен), но лучше его не трогать — это снижает нагрузку на фильтры и исключает потенциальное влияние.

Типичная конфигурация: все правила для конкретного трафика задаются с высоким приоритетом и действием bypass, а в самом конце ставится правило-«заглушка» с самым низким приоритетом, без условий совпадения и с действием bypass. Таким образом, всё, что не попало под явные правила отправки на фильтры, байпасится.

4.4.2. Отправка трафика на группу балансировки

Действие action balancing s_mac отправляет совпавший трафик в указанную группу балансировки (balance group) для распределения по фильтрам. Параметр s_mac означает балансировку по source IP, destination IP и протоколу.

Пример правила: «все пакеты с VLAN ID = 1 отправить на группу балансировки group_filter». Трафик конкретного VLAN будет обработан фильтрами, а весь остальной трафик, не попавший под это правило, — байпасится.

Условия совпадения (match) могут включать:

Критерий	Описание
VLAN ID	Номер VLAN-тега (один или несколько)
IPv4 src/dst	Адрес или подсеть источника/назначения
L4 port	Порт TCP/UDP
MAC-адрес	Source или destination MAC
MPLS	Количество MPLS-меток
Глубина тегов	Количество VLAN-тегов в пакете

В одном правиле можно комбинировать несколько условий (например, VLAN + IPv4-подсеть). Матчить можно как для включения трафика в обработку, так и наоборот — для исключения.

4.5. Балансировка трафика

4.5.1. Хэш-сумма: source IP + destination IP + протокол

Балансировка трафика по фильтрам выполняется на основе хэш-суммы, вычисляемой по трём параметрам IP-пакета:

1. Source IP — адрес источника;
2. Destination IP — адрес назначения;
3. IP-протокол — номер протокола (TCP, UDP и т.д.).

Для вычисления хэша балансировщик разбирает стек заголовков инкапсуляции (VLAN-теги, MPLS-метки) и добирается до IP-заголовка. Если IP-пакет не обнаружен, трафик прозрачно пропускается (байпасится), не отправляясь на фильтры.

Балансировка работает эффективно за счёт огромного количества сессий в реальном операторском трафике. Произведение количества source IP × destination IP × протоколов даёт число, достаточное для равномерного распределения по всем фильтрам и ядрам. Однако одну единственную сессию (один source IP, один destination IP, один протокол) разбалансировать невозможно — весь её трафик попадёт на один фильтр и одно ядро.

4.5.2. Учёт количества ядер фильтров

Параметр N_UNIT_QA на балансировщике задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение всегда равно общему количеству ядер процессора фильтра минус один, поскольку одно ядро является сервисным — на нём работает ОС Linux, системные логи, управление. Все остальные ядра отданы процессу EcoNAT для обработки трафика.

Параметр N_UNIT_QA напрямую влияет на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между ядрами каждого фильтра.

4.5.3. Дополнительный 4-байтный заголовок для фильтров

В точке балансировки к пакету добавляется дополнительный 4-байтовый заголовок. По структуре он похож на VLAN-тег, но VLAN-тегом не является. Этот заголовок выполняет две функции:

1. Для фильтра — сообщает, на какое ядро направить данный пакет для обработки;
2. Для балансировщика — при возврате обработанного пакета от фильтра определяет, в какой операторский линк вернуть пакет.

Фильтр после обработки возвращает пакет с тем же 4-байтовым заголовком. Балансировщик считывает заголовок, определяет исходный линк, удаляет заголовок и отправляет пакет обратно оператору.

4.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро

Хэш-функция балансировщика симметрична: при вычислении хэша для обратного пакета (от интернета к абоненту) source и destination IP меняются местами, но итоговая хэш-сумма совпадает с прямым пакетом.

Это гарантирует:

• оба направления одной сессии всегда попадают на один и тот же фильтр;
• более того — на одно и то же ядро этого фильтра;
• сессия никогда не распределяется по разным фильтрам.

Благодаря этому фильтр всегда видит полную картину сессии (и запрос, и ответ), что критически важно для корректной работы DPI-анализа. Сессию любого абонента можно найти на одном конкретном фильтре.

Важно: балансировщик не ведёт логов о том, куда отправил конкретный пакет — вся обработка происходит на аппаратном уровне. Чтобы найти, на каком фильтре «приземлилась» конкретная сессия, необходимо обойти все фильтры площадки. При 2–3 фильтрах это делается вручную; при большем количестве (до 15) — автоматизируется скриптом.

4.6. Отказоустойчивость

4.6.1. Keep-alive пакеты к фильтрам

Балансировщик непрерывно контролирует доступность фильтров, отправляя keep-alive пакеты через каждую пару портов (filter group) в сторону фильтров.

Принцип работы:

1. Балансировщик отправляет keep-alive через LAN-порт filter group;
2. Пакет проходит через фильтр (заворачивается на первой проверке, т.к. не является IP-пакетом);
3. Пакет возвращается через парный WAN-порт;
4. Балансировщик фиксирует время прохождения (time of pass) — в штатном режиме порядка 27 микросекунд.

Параметры keep-alive настраиваются в профиле проверки доступности (availability profile):

Параметр	Описание
Начальная задержка	Время ожидания после старта перед началом отправки
Интервал	Периодичность отправки (типично ~100 мс)
Порог потерь	Число потерянных пакетов для признания группы неактивной (типично 5)
Порог восстановления	Число успешных пакетов для восстановления активности
Мин. количество активных пар	Порог, ниже которого вся balance group считается неактивной

Keep-alive пакеты проверяют не только физическую доступность канала, но и работоспособность фильтра в целом: если «мозг» фильтра завис или перегружен настолько, что не может обрабатывать даже не-IP-пакеты, keep-alive не вернётся, и балансировщик это обнаружит.

4.6.2. Программный байпас при потере группы портов

При потере keep-alive пакетов для конкретной filter group балансировщик переводит эту группу в состояние программного байпаса: трафик, предназначенный для данной пары портов, не отправляется на фильтр, а заворачивается обратно с LAN-порта на WAN-порт (и наоборот) непосредственно на балансировщике.

Ключевые особенности:

• Программный байпас применяется индивидуально к каждой filter group — остальные группы продолжают работать;
• Переключение не вызывает флапов линков оператора — оператор ничего не заметит;
• Единственное последствие — часть трафика временно перестаёт фильтроваться;
• При восстановлении доступности фильтра группа автоматически возвращается в активное состояние.

Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса приводила к переключению всей площадки на байпас с флапами линков у оператора.

Программный байпас можно также включить вручную — для диагностики или при проведении технических работ. Существует возможность перевести все фильтры в режим программного байпаса одной командой, полностью исключив ТСПУ из обработки трафика без влияния на оператора.

4.6.3. Перебалансировка трафика (опционально)

Альтернативой программному байпасу является перебалансировка трафика на оставшиеся рабочие filter group. Эта возможность настраивается в профиле проверки доступности, но, как правило, отключена по следующим причинам:

• Перебалансировка занимает время и вычислительные ресурсы;
• Происходит пересчёт хэша для всех сессий — сессии могут попасть на другие фильтры;
• Существующие сессии на «старых» фильтрах разрываются (фильтр теряет контекст сессии);
• В общем случае это может быть нежелательно.

Рекомендуемый подход для федерального проекта: программный байпас на уровне отдельной filter group без перебалансировки. Часть трафика временно не фильтруется — это меньшее зло, чем перерыв в работе всей площадки или разрыв всех сессий.

4.7. Работа с различными инкапсуляциями (VLAN, MPLS)

Балансировщик не снимает и не модифицирует никакие теги, метки и заголовки инкапсуляции. Вся обработка ограничивается чтением заголовков:

• VLAN-теги — могут использоваться в условиях match для правил фильтрации (например, байпас служебного VLAN);
• MPLS-метки — балансировщик может определить их наличие и количество, но матчить по конкретным значениям MPLS-меток не имеет практического смысла;
• QinQ (двойные VLAN-теги) — поддерживается чтение с учётом глубины тегов.

Для вычисления хэша балансировщик разбирает весь стек инкапсуляции и добирается до IP-заголовка. Это облегчает работу фильтра, у которого ограничения на типы инкапсуляции несколько строже.

Пакет передаётся на фильтр в неизменном виде (с добавлением только 4-байтового заголовка балансировки). Все VLAN-теги, MPLS-метки и прочие заголовки сохраняются.

4.8. Обработка HTTP-редиректов и TCP Reset через фильтры

При блокировке ресурсов фильтру необходимо отправить абоненту HTTP-редирект (код 302, перенаправление на страницу-заглушку) или TCP Reset (для HTTPS-трафика). Особенность связана с тем, что канал между балансировщиком и фильтром фактически однонаправленный с точки зрения конкретного порта.

Если трафик содержит MPLS-метки или другую инкапсуляцию, фильтр не может самостоятельно сгенерировать ответный пакет с правильными заголовками. Поэтому используется следующая логика:

1. Пакет от абонента в сторону интернет-ресурса пропускается как есть;
2. Фильтр ожидает обратный пакет от интернет-ресурса в рамках той же сессии;
3. Когда обратный пакет приходит (уже с корректными MPLS-метками и заголовками), фильтр подменяет его содержимое на HTTP-редирект или TCP Reset;
4. Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции.

Для HTTP — подставляется редирект на страницу-заглушку. Для HTTPS — отправляется TCP Reset (так как содержимое зашифровано и подмена невозможна). В обоих случаях механизм одинаков: дождаться ответа сервера и подменить пакет.

---

← Оглавление · ← Раздел 3: Байпас · Раздел 5: Фильтр →