DanielLavrushin_tspu-docs/docs/balancer-config.md

# 8. Балансировщик: конфигурация

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

---

Настройка балансировщика (EcoFilter Balancer) начинается после установки прошивки и конфигурации сегмента управления. В отличие от фильтра, на балансировщике **нет дефолтной конфигурации** — все секции (порты, линки, группы балансировки, фильтры) необходимо создавать вручную.

## 8.1. CLI: операционный режим / конфигурационный режим (`edit`)

CLI балансировщика, как и у фильтра, имеет **два режима** работы:

| Режим                | Переход              | Назначение                                |
| -------------------- | -------------------- | ----------------------------------------- |
| **Операционный**     | по умолчанию         | Просмотр информации: команды `show`       |
| **Конфигурационный** | команда **`edit`**   | Изменение всех настроек устройства        |

> **Отличие от фильтра:** на фильтре для перехода в конфигурационный режим используется команда `config`, а на балансировщике — **`edit`**.

### 8.1.1. Интерфейс похож на Juniper CLI

Интерфейс командной строки балансировщика **очень похож на CLI Juniper**. Настройки задаются с помощью команды `set`:

```text
    set <путь> <параметр> <значение>
```

Для тех, кто знаком с оборудованием Juniper, работа с CLI балансировщика не вызовет затруднений.

### 8.1.2. `apply` — применить, `save` — сохранить в startup

После внесения изменений их необходимо применить и сохранить:

```text
    Внесение изменений  ──►  apply  ──►  save
         │                      │           │
         │                      │           └─ Сохранение в startup-config
         │                      │              (переживёт перезагрузку)
         │                      │
         │                      └─ Применение конфигурации
         │                         (изменения вступают в силу)
         │
         └─ Изменения только в буфере
            (не активны, не сохранены)
```

| Команда     | Действие                                                                  |
| ----------- | ------------------------------------------------------------------------- |
| **`apply`** | Применяет конфигурацию — изменения вступают в силу                        |
| **`save`**  | Сохраняет конфигурацию в startup-config (переживёт перезагрузку)          |

> **Важно:** в прошивке пилотного проекта (Урал) команда `apply` одновременно и применяла, и сохраняла конфигурацию в startup-config. В текущих (федеральных) прошивках это поведение изменено: `apply` только применяет, а для сохранения нужна отдельная команда `save`.

## 8.2. Обновление прошивки: `call rdp firmware download` / `call rdp install`

Обновление прошивки балансировщика выполняется в **два этапа** — скачивание и установка:

### Этап 1: Скачивание

```text
    call rdp firmware download <URL> <имя_файла>
```

Скачивает образ прошивки с указанного URL и сохраняет его на устройстве под указанным именем.

### Этап 2: Установка

```text
    call rdp install <имя_файла>
```

Устанавливает прошивку из указанного файла. По завершении команда выводит результат — `OK` или сообщение об ошибке.

### Дополнительные команды

| Команда                          | Действие                                               |
| -------------------------------- | ------------------------------------------------------ |
| `call rdp firmware list`         | Показать список файлов прошивок на устройстве          |
| `call rdp firmware delete`       | Удалить файл прошивки                                  |
| `call rdp firmware set-active`   | Установить активную прошивку на указанный раздел       |
| `show rdp firmware version`      | Показать состояние прошивок (версия, активность, tries) |

### 8.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин)

Как и на фильтре, балансировщик хранит **два раздела** прошивок — **A** и **B**:

| Раздел | Описание                                                   |
| ------ | ---------------------------------------------------------- |
| **A**  | Первый раздел для прошивки                                 |
| **B**  | Второй раздел для прошивки                                 |

Для каждого раздела отображается:

- **Активность** — активна эта прошивка или нет;
- **Версия** — номер версии прошивки;
- **Tries** — счётчик попыток загрузки.

Новая прошивка всегда устанавливается **вместо неактивной** в данный момент.

**Механизм автоматического rollback:**

Балансировщик отслеживает **количество неудачных попыток** загрузки с конкретной прошивки. Если устройство **более 3 раз подряд** не смогло загрузиться с определённой прошивки в течение приблизительно **20 минут**, эта прошивка считается **ненадёжной**, и балансировщик автоматически переключается на другой раздел.

> **Практический совет:** если вам нужно несколько раз перезагрузить балансировщик в короткий промежуток времени (например, для тестирования), помните о лимите в 3 перезагрузки. После третьей перезагрузки за короткий период прошивка будет признана нестабильной. Количество попыток и временной интервал **не настраиваются** — они зашиты в прошивке.

### 8.2.2. `call rdp firmware reset-tries`

Для сброса счётчика попыток загрузки используется команда:

```text
    call rdp firmware reset-tries
```

Эта команда обнуляет значение **tries**, позволяя продолжить перезагрузки без риска автоматического переключения на другой раздел. В промышленной эксплуатации эта команда практически не требуется, но знать о ней полезно.

## 8.3. Настройка физических портов

Настройка физических портов — это **первый шаг** конфигурации балансировщика. Поскольку дефолтной конфигурации нет, все порты необходимо создавать вручную.

Для каждого порта задаются следующие параметры:

| Параметр        | Описание                                                     |
| --------------- | ------------------------------------------------------------ |
| **Имя порта**   | Произвольное имя (рекомендуется формат `p<порт>-<линия>`, для 100G — `p<порт>`) |
| **number**      | Номер физического интерфейса на лицевой панели (1–32)        |
| **lane**        | Номер линии внутри физического порта (1–4)                   |
| **speed**       | Скорость порта: 10G, 25G или 100G                            |
| **mtu**         | Максимальный размер кадра                                    |
| **description** | Текстовое описание порта                                     |

Пример конфигурации двух 10-гигабитных портов на одном физическом интерфейсе:

```text
    set ports p2-1 number 2 lane 1 speed 10g
    set ports p2-2 number 2 lane 2 speed 10g
```

### 8.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed)

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

```text
    p<номер_порта>-<номер_линии>
```

Например:

| Имя порта | Физический порт | Линия | Скорость | Описание                             |
| --------- | --------------- | ----- | -------- | ------------------------------------ |
| `p2-1`    | 2               | 1     | 10G      | Порт 2, линия 1 — первый 10G-канал  |
| `p2-2`    | 2               | 2     | 10G      | Порт 2, линия 2 — второй 10G-канал  |
| `p2`      | 2               | —     | 100G     | Порт 2, все линии — 100G-канал      |

### 8.3.2. 10G: указание lane (1–4), 100G: все lane задействованы

Поведение параметра **lane** зависит от выбранной скорости:

**При 10G (или 25G):**

Каждый физический порт QSFP28 содержит 4 линии. При использовании гидры (breakout-кабеля) каждая линия становится отдельным 10-гигабитным портом. Для каждого такого порта необходимо явно указать номер линии (`lane 1`, `lane 2`, `lane 3`, `lane 4`):

```text
    set ports p2-1 number 2 lane 1 speed 10g
    set ports p2-2 number 2 lane 2 speed 10g
    set ports p2-3 number 2 lane 3 speed 10g
    set ports p2-4 number 2 lane 4 speed 10g
```

В результате из одного физического QSFP28-разъёма получается **4 независимых порта** по 10 Гбит/с.

**При 100G:**

Все 4 линии объединены в один канал. Параметр `lane` **не указывается**, так как задействованы все линии:

```text
    set ports p2 number 2 speed 100g
```

> **Рекомендация:** все физические порты настраиваются в соответствии со схемой организации связи на конкретной площадке. Единых «стандартных» настроек нет — конфигурация полностью зависит от того, какие устройства и на каких скоростях подключены к балансировщику.

## 8.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора)

**Линк** (link) в терминологии балансировщика — это объединение **двух портов** (LAN и WAN) в сторону оператора связи:

```text
    Оператор связи
         │
    ┌────┴────┐
    │ Байпас  │
    └──┬───┬──┘
       │   │
      LAN WAN  ← это один линк
       │   │
    ┌──┴───┴──┐
    │Балансир.│
    └─────────┘
```

Каждый линк всегда содержит **ровно один LAN-порт** и **ровно один WAN-порт**.

Настройка линка:

```text
    set links <имя_линка> lan-port <имя_LAN_порта> wan-port <имя_WAN_порта>
    set links <имя_линка> description "<описание>"
```

Пример:

```text
    set links link1 lan-port p2-2 wan-port p2-1
    set links link1 description "Bypass1-Mon0/Mon1"
```

| Параметр         | Описание                                                    |
| ---------------- | ----------------------------------------------------------- |
| **Имя линка**    | Произвольное название (рекомендуется единообразная схема)   |
| **lan-port**     | Порт в сторону абонентов (LAN)                              |
| **wan-port**     | Порт в сторону интернета (WAN)                              |
| **description**  | Описание — к какому байпасу и интерфейсу подключен линк     |

> **Рекомендация:** в описании линка указывайте, к какому конкретно байпасу и к каким его интерфейсам подключён данный линк. Это значительно упрощает диагностику.

## 8.5. Настройка группы балансировки

После настройки портов и линков необходимо создать **группу балансировки** (balance group) и привязать к ней группы портов в сторону фильтров.

```text
    Линки (оператор)     Группа балансировки     Фильтры
         │                      │                    │
    ┌────┴────┐          ┌──────┴──────┐      ┌─────┴─────┐
    │ link1   │          │             │      │ Filter    │
    │ link2   │──────►   │  Balance    │──────│ Group 1   │──► Фильтр 1
    │ link3   │  Flow    │  Group      │      │ Group 2   │──► Фильтр 1
    │  ...    │  rules   │             │      │ Group 3   │──► Фильтр 2
    └─────────┘          └──────┬──────┘      │  ...      │
                                │              └───────────┘
                         Профиль Keep-Alive
                         (liveness)
```

### 8.5.1. Привязка групп портов в сторону фильтров (filter groups)

К группе балансировки привязываются **filter groups** — пары портов (LAN + WAN) в сторону фильтров:

```text
    set balance-group <имя_группы> filter-group <имя_filter_group> lan-port <порт> wan-port <порт>
```

Количество filter groups определяется количеством пар интерфейсов в сторону фильтров:

| Конфигурация площадки                        | Количество filter groups |
| -------------------------------------------- | ------------------------ |
| 1 фильтр, 16 портов (8 пар LAN/WAN)         | 8                        |
| 10 фильтров, 16 портов каждый (80 пар)       | 80                       |

Каждая filter group объединяет один LAN-порт и один WAN-порт, смотрящие в сторону конкретной пары интерфейсов фильтра.

### 8.5.2. nat-unit-queues: количество ядер фильтра минус один

Параметр **`nat-unit-queues`** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика:

```text
    set ecofilter-balancer nat-unit-queues <число>
```

Значение **всегда равно общему количеству ядер процессора фильтра минус один**:

| Модель фильтра                | Ядер всего | nat-unit-queues |
| ----------------------------- | ---------- | --------- |
| Xeon 2695 (18 ядер)           | 18         | 17        |
| Xeon 2699 (22 ядра)           | 22         | 21        |
| Xeon Gold 6212 (24 ядра)      | 24         | 23        |

Причина вычитания единицы: на фильтре **все ядра, кроме одного**, отданы под процесс EcoNAT, который обрабатывает трафик. Одно ядро — **сервисное**: на нём работает Linux, системные логи, управление. Оно не участвует в обработке трафика.

Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр `cores`).

## 8.6. Профиль Keep-Alive (liveness profile)

К группе балансировки привязывается **профиль Keep-Alive** (liveness profile, параметр группы `liveness-profile`), определяющий параметры отправки keep-alive-пакетов через группы портов в сторону фильтров.

Профиль настраивается отдельно:

```text
    set liveness profile <имя_профиля> active-pairs <число>
    set liveness profile <имя_профиля> initial-delay <мс>
    set liveness profile <имя_профиля> interval <мс>
    set liveness profile <имя_профиля> probes-down-count <число>
    set liveness profile <имя_профиля> probes-up-count <число>
```

### 8.6.1. Допустимая задержка, интервал, пороги потерь и восстановления

| Параметр                   | Описание                                                             |
| -------------------------- | -------------------------------------------------------------------- |
| **`initial-delay`**        | По руководству производителя — максимально допустимая задержка между keep-alive-пакетами, при превышении которой срабатывает счётчик потерь; по эксплуатационным описаниям — пауза перед началом отправки keep-alive после поднятия интерфейсов, чтобы фильтр успел их инициализировать (например, 1000 мс). Подробнее — [раздел 6.6.1](balancer.md) |
| **`interval`**             | Периодичность отправки keep-alive-пакетов, мс (например, 100)        |
| **`probes-down-count`**    | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5) |
| **`probes-up-count`**      | Количество последовательно полученных ответов, после которых неактивная filter group снова считается **активной** (например, 5) |

Механизм работы: балансировщик отправляет keep-alive пакет в LAN-порт filter group и ожидает получить его через парный WAN-порт. Время прохождения пакета (`time-on-path`) измеряется в наносекундах — например, около 27 мкс; конкретное значение зависит от площадки.

При потере заданного количества последовательных пакетов filter group переводится в состояние **bypass** — трафик не отправляется на фильтр, а перекладывается из одного порта в другой на уровне логики балансировщика.

### 8.6.2. Минимальное количество активных пар

Параметр **минимальное количество активных пар** (`active-pairs`) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной.

Пример: если задано значение 8, то группа балансировки будет считаться рабочей, пока хотя бы 8 filter groups активны — неважно, сколько их всего.

> **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, балансировщик прекращал отправку heartbeat на байпас GL Sun, и тот переводил линки в аппаратный байпас с флапом у оператора ([раздел 5.3.1](bypass.md)). Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко.

### 8.6.3. Перебалансировка: включение/выключение

Параметр **перебалансировки** (`rebalance`, значения enable/disable) задаётся в настройках группы балансировки, а не в профиле Keep-Alive, и определяет, что происходит при выходе из строя одной из filter groups:

| Значение        | Поведение                                                              |
| --------------- | ---------------------------------------------------------------------- |
| **Включена**    | Трафик пересчитывается и распределяется по оставшимся filter groups    |
| **Выключена**   | Для упавшей filter group включается программный bypass, остальные работают без изменений |

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

> **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или массовый переезд сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную.

## 8.7. Настройка фильтров (Flow rules)

**Фильтр** на балансировщике — именованный набор правил (flows), который привязывается к линкам в сторону оператора (параметр `apply-to-links`, [раздел 8.7.4](#874-привязка-фильтров-к-линкам)). Каждое правило состоит из условия (match) и действия (action); порядок проверки задаёт приоритет (priority, [раздел 8.7.3](#873-приоритеты-правил)):

| Часть      | Описание                                                    |
| ---------- | ----------------------------------------------------------- |
| **Match**  | Условия, по которым отбирается трафик (заголовки пакетов)   |
| **Action** | Действие с пакетом при совпадении                           |

### 8.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов

Доступные условия для match-секции:

| Условие                | Описание                                          |
| ---------------------- | ------------------------------------------------- |
| **VLAN ID**            | Номер VLAN-тега (например, `vlan 0 id 1`)         |
| **IPv4 source**        | IP-адрес источника (с маской / префиксом)         |
| **IPv4 destination**   | IP-адрес назначения (с маской / префиксом)        |
| **L4 port**            | Порт транспортного уровня (TCP/UDP)               |
| **MAC address**        | MAC-адрес источника или назначения                |
| **MPLS labels**        | Количество MPLS-меток                             |
| **Глубина VLAN-тегов** | Количество VLAN-тегов (для QinQ)                  |

В одном правиле можно комбинировать **несколько условий** одновременно. Например, одновременно проверять VLAN ID и IPv4-подсеть.

Match-условия можно использовать как для **включения** трафика в обработку, так и для **исключения** определённого трафика.

### 8.7.2. Actions: `balancing-as mag-hash` → balance group / `bypass`

Действие (action) определяет, что происходит с пакетом при совпадении:

| Action                  | Описание                                                         |
| ----------------------- | ---------------------------------------------------------------- |
| **balancing-as mag-hash** | Отправить трафик на группу балансировки. Балансировка выполняется по хэшу от source IP, destination IP и протокола |
| **bypass**              | Пропустить трафик прозрачно — переложить из одного порта в другой, не отправляя на фильтры |

При использовании `balancing-as mag-hash` дополнительно указывается **целевая группа балансировки**:

```text
    set filters <имя_фильтра> flows <имя_правила> action balancing-as mag-hash
    set filters <имя_фильтра> flows <имя_правила> to-balance-group <имя_группы>
```

Пример правила, отправляющего трафик с VLAN ID 1 на фильтры:

```text
    set filters main flows traffic-to-filter-1 match vlan 0 id 1
    set filters main flows traffic-to-filter-1 action balancing-as mag-hash
    set filters main flows traffic-to-filter-1 to-balance-group group-filter
    set filters main flows traffic-to-filter-1 priority 100
```

Пример правила bypass для всего остального трафика:

```text
    set filters main flows default-bypass action bypass
    set filters main flows default-bypass priority 1
```

### 8.7.3. Приоритеты правил

Каждому правилу назначается **приоритет** (priority), определяющий порядок обработки. Пакет проверяется по правилам в порядке убывания приоритета — от **высшего** к **низшему**. Первое совпавшее правило определяет действие.

Типовая структура правил:

```text
    Приоритет    Правило                        Action
    ─────────────────────────────────────────────────────
    100          VLAN 1 → на фильтр             balancing-as mag-hash
     90          VLAN 2 → на фильтр             balancing-as mag-hash
     80          VLAN 3 → на фильтр             balancing-as mag-hash
     ...         ...                            ...
      1          Всё остальное → bypass          bypass
```

Правило с **самым низким приоритетом** и **без match-условий** (совпадает со всем) обычно задаёт action `bypass`. Это означает: всё, что не попало под предыдущие правила, пропускается прозрачно.

> **Применение для диагностики:** при траблшутинге можно создать правило с высоким приоритетом, которое перехватывает трафик конкретного VLAN и выполняет action `bypass`. Это позволяет исключить конкретный трафик из обработки фильтрами и проверить, влияет ли ТСПУ на проблему. По статистике правила (количество пакетов/байт) можно убедиться, что трафик действительно проходит через это правило.

### 8.7.4. Привязка фильтров к линкам

После настройки правил необходимо **привязать фильтр к линкам** — указать, на каких линках (в сторону оператора) данные правила будут действовать:

```text
    set filters <имя_фильтра> apply-to-links [ <линк1> <линк2> ... ]
```

Пример:

```text
    set filters main apply-to-links [ link1 link2 link3 link4 ]
```

Один набор правил (фильтр) может быть привязан к **нескольким линкам** одновременно. Все линки, привязанные к фильтру, используют одни и те же flow rules.

## 8.8. Настройка Heartbeat для GL Sun (пилотный проект)

Данная настройка актуальна **только для пилотного проекта на Урале**, где используются байпасы GL Sun. В федеральном проекте с байпасами Silicom эта настройка **не требуется** — Silicom самостоятельно генерирует и проверяет heartbeat-пакеты.

На Урале балансировщик работает в активном режиме и сам должен отправлять heartbeat-пакеты на байпас GL Sun:

| Параметр                    | Описание                                                        |
| --------------------------- | --------------------------------------------------------------- |
| **IPv4-адрес байпаса**      | IP-адрес байпаса GL Sun (`ipv4`)                                 |
| **Порт**                    | TCP- или UDP-порт байпаса для heartbeat (`tcp-port` / `udp-port`, по умолчанию 4001) |
| **Период отсылки**          | Периодичность отправки heartbeat (`watchdog-delay`), в микросекундах; рекомендованное значение — 30 мс (30000), по умолчанию — 10000 (10 мс) |
| **Группа балансировки**     | Группа, для которой работает отправка heartbeat (`balance-group`) |
| **Список линков байпаса**   | Идентификаторы сущностей на стороне байпаса GL Sun (`links`)    |
| **ToS**                     | Тип сервиса в IP-заголовке heartbeat-пакетов (`type-of-service`, по умолчанию 184) |
| **Автоматический возврат**  | Возможность автоматического возврата трафика в режим primary при восстановлении группы балансировки (`autoreturn`) |

Параметры задаются в профиле heartbeat (`bypass-unit profile`), а линк балансировщика связывается с линком байпаса параметром `bypass-unit link-id` в настройках линка.

Heartbeat-пакеты отправляются только при условии, что **группа балансировки находится в состоянии Active**. При переходе группы в неактивное состояние отправка прекращается, и связь с байпасом (по TCP) разрывается — состояние переходит в `disconnected`.

> **Примечание:** с байпасами Silicom логика работы другая — Silicom самостоятельно отсылает heartbeat и проверяет доступность интерфейсов, а балансировщик прозрачно пропускает эти пакеты между своими портами.

## 8.9. Management-интерфейс: IP, маска, default gateway

Настройка management-интерфейса балансировщика выполняется аналогично другим сетевым устройствам:

```text
    set management ip <IP-адрес>
    set management mask <маска_подсети>
    set management default-gateway <IP-шлюза>
```

Management-интерфейс обеспечивает доступ к устройству по SSH и используется для управления, мониторинга и взаимодействия с ЦСУ.

> **Напоминание:** management Ethernet работает **только** на скорости 1 Гбит/с (см. [раздел 7.2](balancer-platform.md)).

---

## Общий порядок настройки балансировщика

Для наглядности — последовательность настройки балансировщика «с нуля»:

```text
    1. Установить прошивку
           │
    2. Настроить management-интерфейс
           │
    3. Настроить физические порты (ports)
           │
    4. Настроить линки (links) — пары LAN/WAN в сторону оператора
           │
    5. Настроить группу балансировки (balance group)
       └── Создать filter groups (пары портов в сторону фильтров)
       └── Задать nat-unit-queues
       └── Привязать профиль Keep-Alive
           │
    6. Настроить профиль Keep-Alive (liveness profile)
           │
    7. Настроить фильтры (flow rules) — правила обработки трафика
       └── Привязать фильтры к линкам
           │
    8. apply + save
```

---

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