# 6. Балансировщик: принцип работы

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

---

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

Балансировщик (EcoFilter Balancer) — это **высокопроизводительный программируемый коммутатор**. Его основная задача — принимать трафик операторских каналов от байпасов и **равномерно распределять** его по подключённым фильтрам, а внутри каждого фильтра — по его процессорным ядрам. Для сети оператора балансировщик, как и остальное оборудование ТСПУ, прозрачен на уровне L2.

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

- **согласование скоростей** — операторские каналы (как правило, 10G и 100G) распределяются по портам фильтров, которые в проекте в большинстве случаев подключаются интерфейсами 10G. Число фильтров определяется только объёмом трафика, поэтому число портов в сторону фильтров не совпадает с числом операторских каналов;
- **исключение служебного трафика** — возврат оператору без обработки трафика, который не нужно отправлять на фильтры (правила с действием bypass, [раздел 6.4](#64-фильтры-на-балансировщике-flow-rules));
- **контроль доступности фильтров** — отправка keep-alive-пакетов через каждую пару портов в сторону фильтров;
- **программный байпас** — вывод из обработки отдельной пары портов или всех фильтров сразу без флапа линков у оператора;
- **прозрачный пропуск heartbeat-пакетов** байпаса Silicom между парными портами линка ([раздел 5.4](bypass.md)).

Балансировщик работает только с заголовками пакетов уровней L2–L4 и **ничего не знает** о том, что происходит на фильтрах: распознавание протоколов, DPI-листы и блокировки его не касаются. По документации производителя он поддерживает также прозрачный режим с зеркалированием: трафик пропускается мимо фильтров, а на фильтры отправляется только копия. В проекте фильтры в режиме копии трафика не используются; для вывода фильтров из обработки служит программный байпас ([раздел 6.6.2](#662-программный-байпас-при-потере-группы-портов)).

В ТСПУ тип А используется балансировщик **EcoFilter Balancer**; в эшелонированной системе (ТСПУ тип Б) на той же аппаратной платформе работает балансировщик с другим программным обеспечением — **Eco Highway** ([раздел 4](echelon.md)). Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. В простейшей конфигурации — один-два канала и один фильтр — балансировщик не нужен, и байпас подключается к фильтру напрямую ([раздел 2.3](traffic-flow.md)).

С завода балансировщик поставляется с заводской (factory) прошивкой ограниченной функциональности и базовой версией рабочей прошивки, но **без рабочей конфигурации**. После установки нужной версии прошивки и настройки сегмента управления в конфигурации нет ни линков, ни групп балансировки, ни правил, а все используемые порты нужно настроить самостоятельно — всё это создаётся при проектировании конкретного узла ([раздел 8](balancer-config.md)).

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

| Параметр                   | Значение                                                                          |
| -------------------------- | --------------------------------------------------------------------------------- |
| **Форм-фактор**            | 1U                                                                                |
| **Порты**                  | 32 × QSFP28                                                                       |
| **Пропускная способность** | 3,2 Тбит/с; скорость провода обеспечивается на пакетах размером более 160 байт    |
| **Скорости портов**        | Платформа поддерживает 10/25/40/50/100GE (в зависимости от настроек и трансиверов); типовые скорости в проекте — 10G и 100G |
| **Питание**                | 2 блока питания с горячим резервированием                                         |
| **Передняя панель**        | Консоль, порт управления Ethernet (работает только на 1 Гбит/с), USB, диагностический разъём |

Существуют также двухюнитовые балансировщики на 65 портов, но в проекте АСБИ используются **только одноюнитовые**. По техническому описанию производителя в основе балансировщика — P4-программируемый коммутатор; одноюнитовой 32-портовой модели соответствует платформа EcoSwitch 1032, в линейке есть также модель 2065 (2U, 65 × QSFP28, до 6,4 Тбит/с). Коммутационный чип платформы — Barefoot Tofino.

Каждый порт QSFP28 состоит из четырёх линий (lane) по 25 Гбит/с. На скорости 100G задействованы все четыре линии; если настроить каждую линию отдельно на 10G, один физический порт даёт до четырёх портов 10G. Для их подключения используются **«гидры»** — breakout-кабели QSFP → 4 × SFP+, оптические или DAC.

Внутри чипа Tofino — два независимых конвейера (pipeline) со своими ресурсами, каждый обслуживает свою половину портов. На EcoFilter Balancer оба конвейера настроены одинаково, поэтому к какому из них относится порт, значения не имеет — в отличие от Eco Highway ([раздел 4.4](echelon.md)). Подробно аппаратная часть описана в [разделе 7](balancer-platform.md).

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

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

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

Порты обеих групп работают **парами** LAN + WAN:

- пара портов в сторону оператора называется **линком** (link). В линк всегда входит ровно один LAN-порт и один WAN-порт — они соответствуют одному разорванному каналу оператора (портам Mon0 и Mon1 одного сегмента байпаса). Имя линка произвольное, но его лучше строить по единому правилу; в описании линка можно указать, к какому байпасу и какому его сегменту он подключён;
- пара портов в сторону фильтра называется **filter group**. Filter groups объединяются в **группу балансировки** (balance group), по которой и распределяется трафик; групп балансировки может быть несколько.

Количество filter groups равно количеству пар портов в сторону фильтров: один фильтр с 16 портами — это 8 filter groups, десять таких фильтров — 80. Filter group — это именно пара портов, а не фильтр целиком: при проблеме с одной парой остальные пары того же фильтра продолжают работать.

Имена портов задаются при настройке. Рекомендуется придерживаться схемы «номер физического порта — номер линии»: p4-2 — вторая линия порта 4 (10G), p10 — порт 10 целиком (100G). Номера портов в примерах условны.

```text
          Оборудование оператора (через байпасы)
            │           │                   │           │
        p4-2 LAN     p4-1 WAN            p10 LAN      p9 WAN
            └─────┬─────┘                   └─────┬─────┘
            Линк 1 (10G)                   Линк 2 (100G)
                  │                               │
     ┌────────────┴───────────────────────────────┴────────────┐
     │                      Балансировщик                      │
     │        фильтры (flow rules) → группа балансировки       │
     └──────┬───────────┬─────────────┬───────────┬────────────┘
        p1-2 LAN     p1-1 WAN     p1-4 LAN     p1-3 WAN   ...
            └─────┬─────┘             └─────┬─────┘
           filter group 1            filter group 2
                  │                         │
          Фильтр 1: te2/te1         Фильтр 1: te4/te3
```

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

На фильтрах разделение портов жёсткое: в каждой паре чётный порт — LAN, нечётный — WAN ([раздел 11.5](filter-platform.md)). На балансировщике жёсткой привязки нет — порт становится LAN или WAN только при настройке линка или filter group. Для однозначности при проектировании принят тот же принцип, что и на фильтрах:

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

Для 10-гигабитных портов чётность определяется по номеру линии: p4-2 — LAN, парный ему p4-1 — WAN. У 100-гигабитных портов номера линии нет, и определяющим является номер порта: p10 — LAN, p9 — WAN. Принцип действует как для портов в сторону операторского оборудования, так и для портов в сторону фильтров. На балансировщике Eco Highway он не соблюдается: там LAN- и WAN-порты разнесены по разным конвейерам ([раздел 4.4.1](echelon.md)).

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

Пакет, вошедший в LAN-порт линка, после обработки выходит только через WAN-порт того же линка, и наоборот: вошедший через p4-2 выйдет только через p4-1, вошедший через p4-1 — только через p4-2. Ни в какой другой порт пакет попасть не может — это сделано специально, чтобы пакеты разных линков никогда не смешивались.

Это правило обеспечивает **прозрачность ТСПУ** для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его в продолжение того же канала, независимо от того, каким фильтром пакет был обработан. Механизм — служебный 4-байтный заголовок, по которому балансировщик узнаёт исходный линк вернувшегося от фильтра пакета ([раздел 6.5.3](#653-дополнительный-4-байтный-заголовок-для-фильтров)).

### 6.3.3. Асимметричный трафик: все линки — на один балансировщик

Оба направления каждого потока должны попадать на один и тот же фильтр и одно его ядро; проще всего это обеспечить, когда оба направления проходят через один и тот же балансировщик. Поэтому на один балансировщик заводятся все линки, по которым могут идти прямое и обратное направления одного и того же трафика. В частности, все каналы одного агрегированного линка (LAG) оператора приходят на один балансировщик: оборудование оператора с каждой стороны распределяет потоки по каналам агрегата своим хэшем, и прямое и обратное направления одной сессии могут оказаться в разных каналах. Поэтому при проектировании узла у оператора выясняют, какие каналы входят в агрегаты.

Речь идёт о случае, когда оба направления проходят через ТСПУ, но по разным каналам. Если одно из направлений вообще минует ТСПУ, тип А такой трафик обработать не может — для этого предназначена эшелонированная система ([раздел 4.2](echelon.md)).

Если одного балансировщика недостаточно, применяется перекрёстная (кроссированная) схема с несколькими балансировщиками, к которым подключены одни и те же фильтры. Чтобы поток попадал на один и тот же фильтр и одно ядро, на какой бы балансировщик он ни пришёл, группы балансировки на всех балансировщиках такой схемы настраиваются одинаково — те же фильтры в том же порядке, то же число ядер; в новых версиях ПО для сверки предусмотрена контрольная сумма конфигурации группы балансировки (`show ecofilter-balancer balancing-config-hash`). В эшелонированной системе такая схема может не подойти, поскольку фильтры там подключаются по схеме on-a-stick ([раздел 4.3.3](echelon.md)).

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

> **Примечание о версиях ПО.** Имена параметров в этой главе — группы балансировки (`balance-groups`) с парами портов `filter-group`, наборы правил `filters` с привязкой `apply-to-links`, действие `balancing-as mag-hash` с `to-balance-group`, параметры `nat-unit-queues` и `rebalance` — относятся к ранней модели конфигурации балансировщика, по которой построен и [раздел 8](balancer-config.md). В новых версиях ПО модель другая: группа балансировки задаётся как `ecofilter-balancer ecofilter-unit` с парами портов `pair` и числом ядер `cores`, правила — как `ecofilter-balancer flow` с действиями `bypass` (по умолчанию), `drop` и `to-ecofilter`, а метод хэширования — одним параметром для всего устройства (`ecofilter-balancer balancing-method`). Логика работы при этом та же.

Термин «фильтр» на балансировщике означает не устройство, а **именованный набор правил**, который привязывается к линкам в сторону оператора (параметр `apply-to-links`). Каждое правило (flow) состоит из трёх частей:

- **match** — условия совпадения;
- **action** — действие с совпавшим пакетом;
- **priority** — приоритет: правила проверяются в порядке приоритета, от высшего к низшему, и срабатывает первое совпавшее. Направление шкалы — больше или меньше число означает более высокий приоритет — в документации производителя описано противоречиво, поэтому его стоит проверять на используемой версии ПО.

Действий в ТСПУ тип А два: отправить трафик на группу балансировки, то есть на фильтры, или вернуть его оператору без обработки (bypass). В документации производителя для новых версий ПО описаны также действие `drop` и блокировка по таблицам, загружаемым с внешнего gRPC-сервера (`external-acl`, действие `block`). В рассматриваемой схеме ТСПУ тип А блокировку выполняют фильтры, а балансировщик трафик не блокирует — в отличие от эшелонированной системы ([раздел 4](echelon.md)).

Правила можно строить двумя способами: перечислить трафик-исключения с действием bypass, а всё остальное отправить на фильтры, — либо, наоборот, перечислить трафик, который нужно отправить на фильтры, а всё остальное вернуть оператору завершающим правилом. Обычно правил на балансировщике ТСПУ тип А немного, они задаются вручную и описывают исключения — например, служебный VLAN возвращается оператору, а весь остальной трафик отправляется на фильтры. На Eco Highway, наоборот, правила загружаются из ЦСУ и исчисляются десятками и сотнями тысяч ([раздел 4.3.1](echelon.md)). По каждому правилу балансировщик считает пакеты и байты; эта статистика используется при диагностике ([разделы 9.5](balancer-monitoring.md) и [23.4](troubleshooting.md)).

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

Действие **bypass** возвращает совпавший трафик оператору через парный порт линка сразу на входе, не отправляя его на фильтры. Так поступают с трафиком, который не нужно и нежелательно анализировать:

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

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

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

Отбором по VLAN пользуются и при подключении BRAS или CGNAT по схеме on-a-stick: на фильтры отправляют только VLAN одного участка — до или после BRAS/CGNAT, в обоих направлениях, — чтобы каждая сессия обрабатывалась один раз ([раздел 3.4.2](placement.md)).

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

Действие балансировки задаётся как `balancing-as mag-hash` — распределение по хэшу от адресов источника, назначения и IP-протокола — вместе с целевой группой (`to-balance-group`): групп балансировки может быть несколько, и правило определяет, в какую из них отправить трафик. В новых версиях ПО этому соответствует действие `to-ecofilter`, а метод хэширования задаётся отдельно для всего устройства ([раздел 6.5.1](#651-хэш-сумма-source-ip--destination-ip--протокол)).

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

Условия совпадения (match) — по документации производителя; имена условий приведены для текущих версий ПО:

| Критерий        | Описание                                                                                     |
| --------------- | -------------------------------------------------------------------------------------------- |
| **VLAN-теги**   | Значения первого, второго и третьего тега (`vlan0-tag`, `vlan1-tag`, `vlan2-tag`) и число тегов в кадре (`vlan-depth`) |
| **MPLS**        | Число MPLS-меток в кадре (`mpls-depth`)                                                      |
| **IPv4 / IPv6** | Адрес или подсеть источника и назначения — с префиксом или маской                            |
| **IP-протокол** | Значение поля протокола (`ip-proto`)                                                         |
| **Порты L4**    | Порты источника и назначения TCP и UDP, а также SCTP, DCCP и UDP-Lite                        |
| **MAC-адреса**  | MAC-адрес источника и назначения, в том числе с маской                                       |
| **Тип кадра**   | EtherType (`packet-type`) и поля LLC                                                         |

В одном правиле можно комбинировать несколько условий, например VLAN и IPv4-подсеть. Настройка правил описана в [разделе 8.7](balancer-config.md).

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

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

Трафик распределяется по filter groups на основе **хэш-суммы** от трёх полей IP-пакета:

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

В новых версиях ПО метод хэширования задаётся для всего устройства параметром `ecofilter-balancer balancing-method`; описанной схеме соответствует метод `layer-3`, он же используется по умолчанию, а в качестве хэш-функции производитель указывает CRC32. Доступны и другие методы — только по адресу назначения (`dst-ip`) и с добавлением портов TCP/UDP (`layer-4`), — но в ТСПУ используется балансировка по адресам и протоколу.

Для вычисления хэша балансировщик разбирает стек инкапсуляции и добирается до IP-заголовка ([раздел 6.7](#67-работа-с-различными-инкапсуляциями-vlan-mpls)). Если IP-пакет не найден, трафик пропускается прозрачно и на фильтры не отправляется.

Балансировка работает за счёт **огромного количества** разных сочетаний «адрес источника — адрес назначения — протокол», реально встречающихся в операторском трафике: когда таких сочетаний много и ни одно из них не несёт заметной доли трафика, хэш распределяет нагрузку по всем filter groups и ядрам достаточно равномерно.

Обратная сторона: порты TCP/UDP в хэш не входят, поэтому **весь трафик между одной парой адресов по одному протоколу** — сколько бы соединений в нём ни было — попадает на одну пару портов одного фильтра и на одно его ядро. Разбалансировать такой поток невозможно: если, например, 200 Гбит/с идут с одного адреса на один адрес по одному протоколу, весь этот трафик будет направлен в одну пару портов и на одно ядро одного фильтра — и в пару портов 10G он физически не поместится. Это стоит учитывать для адресов, за которыми стоит много абонентов, — например, при установке ТСПУ после CGNAT ([раздел 3.3](placement.md)): трафик многих абонентов с одного внешнего адреса к одному и тому же ресурсу (узлу CDN, кэш-серверу, популярному сервису) попадает на одно ядро.

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

Параметр **`nat-unit-queues`** задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение **всегда равно общему количеству ядер процессора фильтра минус один**: все ядра, кроме одного, отданы процессу EcoNAT, обрабатывающему трафик, а одно ядро сервисное — на нём работают Linux, системные логи и управление.

Параметр **напрямую влияет** на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между **ядрами** каждого фильтра. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр `cores`, по умолчанию 1 — поэтому значение нужно задавать явно). Настройка — в [разделе 8.5.2](balancer-config.md).

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

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

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

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

В эшелонированной системе вместо этого заголовка используется VLAN-тег: балансировщик Eco Highway помечает им трафик, а фильтр после обработки меняет его на другой ([раздел 4.3.3](echelon.md)).

Из-за 4-байтного заголовка кадры на участке между балансировщиком и фильтром на 4 байта длиннее исходных: максимальный кадр оператора вместе с заголовком должен укладываться в MTU портов балансировщика в сторону фильтров и в L2 MTU фильтра, иначе крупные кадры будут отбрасываться. В проекте на портах балансировщика выставляется MTU около 9000 байт (по умолчанию 9000, платформа допускает до 10240), а на фильтрах — L2 MTU 9216 ([раздел 15.2.4](filter-interfaces.md)); если оператор использует кадры крупнее, MTU нужно согласовать при проектировании.

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

Хэш вычисляется **симметрично**: у обратного пакета (от интернета к абоненту) адреса источника и назначения поменялись местами, но итоговое значение совпадает со значением для прямого пакета. Сама функция CRC32 несимметрична, так что симметрию обеспечивает способ формирования входных данных хэша.

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

- оба направления одной сессии **всегда попадают на один и тот же фильтр**;
- более того — на одно и то же **ядро** этого фильтра, а если оба направления проходят через один балансировщик, — и на одну и ту же пару портов;
- сессия **никогда не распределяется** по разным фильтрам.

Благодаря этому фильтр всегда видит полную картину сессии — и запрос, и ответ, — что необходимо для корректного распознавания трафика и применения политик. Распределение детерминировано, пока состав группы балансировки не меняется ([раздел 6.6.3](#663-перебалансировка-трафика-опционально)).

Балансировщик **не ведёт логов** о том, куда отправлен конкретный пакет: балансировка выполняется аппаратно, программируемым чипом, на скорости провода. Чтобы найти, на каком фильтре обслуживается сессия абонента, нужно обойти фильтры площадки — вручную, если их два-три, или простым скриптом, если их много (на некоторых площадках — около полутора десятков); скрипт справляется примерно за десяток секунд ([раздел 23.2](troubleshooting.md)).

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

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

Балансировщик непрерывно проверяет каждую filter group **keep-alive-пакетами**. С байпасами Silicom это второй, независимый от heartbeat байпаса контур контроля: heartbeat байпаса проверяет канал до балансировщика и дальше него не проходит, а keep-alive балансировщика — путь до фильтра и обратно ([раздел 5.4](bypass.md)).

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

1. Балансировщик отправляет keep-alive-пакеты в оба порта filter group — в **LAN-порт** и в **WAN-порт**;
2. Пакет проходит через фильтр: keep-alive — служебный не-IP-пакет, и фильтр передаёт его в парный порт сразу, на первой же проверке («IP-пакет или нет»);
3. Пакет возвращается на балансировщик через парный порт той же filter group;
4. Балансировщик фиксирует время прохождения — `time-on-path`, в наносекундах, отдельно для каждого направления (в ранних версиях ПО — `to-lan` и `to-wan` в состоянии filter group, в новых — по портам в выводе `show liveness profile-status`). Например, 27 000 нс, то есть 27 мкс ([раздел 9.6.2](balancer-monitoring.md)).

На фильтре принятые keep-alive-пакеты учитываются счётчиком `cr_pass_ecobalancer_keepalive` — по нему можно убедиться, что пакеты балансировщика до фильтра доходят.

Keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик: даже первую проверку («IP-пакет или нет») выполняет процессор фильтра, поэтому если фильтр завис или перегружен настолько, что не пропускает пакеты, keep-alive не вернётся. Оценивать загрузку фильтра — не основная задача keep-alive, однако сильно перегруженный фильтр — например, при загрузке таблиц сессий заметно выше рекомендованных 20 % — теоретически может начать терять и их ([раздел 9.6](balancer-monitoring.md)).

Параметры проверки задаются в **профиле Keep-Alive** (liveness profile), который привязывается к группе балансировки:

| Параметр                | Назначение                                                                                                      |
| ----------------------- | --------------------------------------------------------------------------------------------------------------- |
| **`initial-delay`**     | Допустимая задержка keep-alive, мс (см. примечание ниже)                                                        |
| **`interval`**          | Периодичность отправки keep-alive-пакетов, мс                                                                   |
| **`probes-down-count`** | Число последовательных потерь, после которого пара портов считается неактивной (DOWN): её трафик уходит в программный байпас, а при включённой перебалансировке перераспределяется по остальным парам |
| **`probes-up-count`**   | Число последовательно полученных keep-alive, после которого пара возвращается в работу                          |
| **`active-pairs`**      | Минимальное число активных пар, при котором группа балансировки целиком считается рабочей                       |

В типовой конфигурации keep-alive отправляются каждые 100 мс, а пара портов считается неактивной после пяти последовательных потерь.

> **Примечание.** Параметр `initial-delay` трактуется по-разному. В руководстве производителя он описан как максимально допустимая задержка между keep-alive-пакетами: при её превышении срабатывает счётчик потерь `probes-down-count`. По названию же и по эксплуатационным описаниям это пауза после загрузки балансировщика или поднятия интерфейсов в сторону фильтров, перед началом отправки keep-alive, — чтобы фильтр успел инициализировать интерфейсы (например, 1000 мс). От трактовки зависит и время обнаружения отказа: если это порог задержки, отказ фиксируется не раньше, чем через `initial-delay` (по умолчанию 8000 мс, в примерах производителя — 6000 мс), а не через `interval` × `probes-down-count`. Точное поведение стоит проверять для используемой версии ПО.

Когда число активных пар в группе балансировки опускается ниже `active-pairs`, неактивной считается вся группа: её состояние становится bypass, и весь её трафик возвращается оператору без обработки.

В пилотном проекте на Урале значение `active-pairs` было равно общему числу пар в сторону фильтров, поэтому проблема с одним-единственным интерфейсом переводила всю группу балансировки в неактивное состояние. Балансировщик прекращал отправку heartbeat-пакетов на оптический байпас GL Sun, и вся площадка уходила в аппаратный байпас с флапом линков у оператора ([раздел 5.3.1](bypass.md)). Такое значение не обязательно — порог можно задать гибче.

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

При потере keep-alive для конкретной filter group балансировщик переводит эту пару портов в **программный байпас**: трафик, который по хэшу приходится на неё, не отправляется на фильтр, а сразу перекладывается с входного порта линка на парный и возвращается оператору.

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

- программный байпас применяется **индивидуально** к каждой filter group — остальные пары продолжают работать;
- переключение **не вызывает флапов** линков оператора — оператор ничего не замечает;
- основное последствие — часть трафика временно не фильтруется; кроме того, возможны кратковременные потери пакетов — пока неисправность ещё не обнаружена и в момент переключения, а после возврата пары в работу сессии, открытые во время байпаса, приходят на фильтр «с середины»;
- когда keep-alive снова начинают проходить, пара **автоматически возвращается** в работу (если перебалансировка выключена);
- о переключении балансировщик пишет в журнал. В стандартный набор SNMP-трапов (перезагрузка, авторизация, состояние физических портов, блоки питания) такое событие не входит; в новых версиях ПО трап на изменение состояния можно настроить отдельно (условие `xpath`). Так система мониторинга узнаёт о проблеме, и её можно устранить.

Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса переводила **всю площадку** в аппаратный байпас с флапом линков у оператора ([раздел 6.6.1](#661-keep-alive-пакеты-к-фильтрам)), а возврат в работу требовал повторного флапа.

Программный байпас можно включить и **вручную** — для диагностики или на время технических работ. Вручную переключается группа балансировки целиком: в новых версиях ПО это команда `call ecofilter-balancer set-bypass-ecofilter-unit` с режимами auto (штатная работа: трафик идёт на фильтры, пока группа активна), bypass (весь трафик группы идёт мимо фильтров) и primary (трафик принудительно направляется на фильтры) ([раздел 9.7](balancer-monitoring.md)); команды ручного переключения перенесены в EcoFilter Balancer из программного байпаса Eco Highway. Так можно одной командой исключить ТСПУ из обработки трафика без какого-либо влияния на линки оператора; такой режим применялся при испытаниях эшелонированной системы.

Если фильтр перегружен и теряет keep-alive, filter group может периодически переключаться между работой и программным байпасом. Физических флапов у оператора это не вызывает, но при каждом переключении теряется небольшое количество пакетов ([раздел 9.6](balancer-monitoring.md)). Чтобы перегрузку заметить раньше, система мониторинга должна отслеживать загрузку таблиц на фильтрах и срабатывать на превышение оптимального значения.

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

Альтернатива программному байпасу — **перебалансировка** (параметр группы балансировки `rebalance`): трафик пропавшей filter group перераспределяется по оставшимся рабочим парам портов. В примерах конфигурации перебалансировка включена, но в проекте её планируется **выключить**, поскольку:

- перебалансировка занимает время и вычислительные ресурсы;
- хэш пересчитывается для всех сессий, и сессии могут перейти на другие пары портов и другие фильтры;
- новый фильтр видит такие сессии «с середины», без начального обмена, а контекст анализа на прежнем фильтре теряется; чтобы такие сессии вообще заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN ([раздел 15.2.6](filter-interfaces.md)).

Производитель описывает этот режим как резервирование N+X: неисправный фильтр исключается из группы балансировки, его потоки перераспределяются между исправными, а при выходе из строя всех фильтров срабатывает режим bypass. В проекте резервирование фильтров по схеме N+1 не предусмотрено: число фильтров рассчитывается так, чтобы пропустить трафик оператора в худшем сценарии; допустим ли при этом выход из строя одного фильтра, определяется расчётом мощностей конкретной площадки ([раздел 1.4](overview.md)).

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

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

Балансировщик **не снимает и не модифицирует** теги, метки и другие заголовки инкапсуляции — он только читает их, чтобы добраться до IP-заголовка. По документации производителя балансировщик разбирает:

- до трёх VLAN-тегов (802.1Q, QinQ);
- до шести MPLS-меток;
- PPPoE;
- туннели GRE и IP-in-IP —

и находит в них пакеты IPv4 и IPv6.

Заголовки инкапсуляции можно использовать в условиях правил: значения VLAN-тегов и их число, число MPLS-меток ([раздел 6.4.2](#642-отправка-трафика-на-группу-балансировки)). Отбора по значениям MPLS-меток среди условий нет, да он и не был бы надёжным: значения меток на линке назначает соседний маршрутизатор оператора (при LDP и RSVP-TE — динамически), и они могут меняться при перестроении LSP.

Балансировщик сам разбирает сложную инкапсуляцию — множество тегов и меток — и сам выбирает ядро фильтра, сообщая его в 4-байтном заголовке, поэтому распределять такой трафик по ядрам фильтру не нужно. Это облегчает работу фильтра, у которого ограничений на типы инкапсуляции и их балансировку больше. Разбирать заголовки для анализа фильтр всё равно должен сам и работает только с IP-пакетом; глубина разбора VLAN-тегов на фильтре задаётся параметром VLAN Mode ([раздел 15.2.1](filter-interfaces.md)).

На фильтр пакет уходит с исходным стеком заголовков и добавленным 4-байтным заголовком балансировки, а обратно оператору — с тем же стеком, с каким пришёл. Кадры, в которых IP-пакет не найден, на фильтры не отправляются и прозрачно передаются в парный порт линка. Heartbeat-пакеты байпаса Silicom также до фильтров не доходят — балансировщик передаёт их между парными портами.

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

При блокировке ресурса фильтр отправляет абоненту **HTTP-редирект** (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») для HTTP или **TCP Reset** для HTTPS: подменить содержимое зашифрованного соединения невозможно, а сам ресурс определяется по SNI в ClientHello ([раздел 17.5.3](filter-dpi.md)). Для трафика без MPLS-меток фильтр формирует такой пакет сам.

С MPLS-трафиком так не получается. MPLS-путь однонаправлен: метки, с которыми пакет абонента пришёл на фильтр, действительны только для направления в сторону интернета, а стек меток обратного направления фильтру неизвестен — собранный им самим пакет оборудование оператора отбросит или доставит не туда. Поэтому для трафика с MPLS-метками используется другая логика:

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

Роль балансировщика здесь двоякая. Разбирая стек меток и вычисляя симметричный хэш по IP-адресам под ними, он приводит ответ сервера на тот же фильтр и то же ядро, которые обработали запрос абонента, хотя метки у ответа другие. А при возврате он не трогает метки и отправляет пакет строго в исходный линк, поэтому подменённый ответ проходит ровно тем же путём, что и настоящий ответ сервера. Решение о блокировке и отправке редиректа или Reset принимает фильтр ([раздел 10.1.5](filter.md)).

---

[← Оглавление](../README.md) · [← Раздел 5: Байпас](bypass.md) · [Раздел 7: Балансировщик: аппаратная платформа →](balancer-platform.md)