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

[← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md)

---

## 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 и далее — в логические сущности, называемые **линками**.

```text
    Оборудование оператора (через байпасы)
          │           │           │           │
        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 (так как содержимое зашифровано и подмена невозможна). В обоих случаях механизм одинаков: дождаться ответа сервера и подменить пакет.

---

[← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md)