souce/tspu-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
tspu-docs/chapters/21.md
Daniel Lavrushin 10fb7f4e18 Добавлены новые разделы: 
- Раздел 22: Балансировщик: мониторинг и диагностика
- Раздел 23: Распознавание протоколов (DPI Engine)
- Раздел 24: Траблшутинг

Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
2026-02-20 13:59:30 +01:00

487 lines
36 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 21. Балансировщик: конфигурация
[← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md)
---
Настройка балансировщика (EcoFilter Balancer) начинается после установки прошивки и конфигурации сегмента управления. В отличие от фильтра, на балансировщике **нет дефолтной конфигурации** — все секции (порты, линки, группы балансировки, фильтры) необходимо создавать вручную.
## 21.1. CLI: операционный режим / конфигурационный режим (`edit`)
CLI балансировщика, как и у фильтра, имеет **два режима** работы:
| Режим | Переход | Назначение |
| -------------------- | -------------------- | ----------------------------------------- |
| **Операционный** | по умолчанию | Просмотр информации: команды `show` |
| **Конфигурационный** | команда **`edit`** | Изменение всех настроек устройства |
> **Отличие от фильтра:** на фильтре для перехода в конфигурационный режим используется команда `config`, а на балансировщике — **`edit`**.
### 21.1.1. Интерфейс похож на Juniper CLI
Интерфейс командной строки балансировщика **очень похож на CLI Juniper**. Настройки задаются с помощью команды `set`:
```text
set <путь> <параметр> <значение>
```
Для тех, кто знаком с оборудованием Juniper, работа с CLI балансировщика не вызовет затруднений.
### 21.1.2. `apply` — применить, `save` — сохранить в startup
После внесения изменений их необходимо применить и сохранить:
```text
Внесение изменений ──► apply ──► save
│ │ │
│ │ └─ Сохранение в startup-config
│ │ (переживёт перезагрузку)
│ │
│ └─ Применение конфигурации
│ (изменения вступают в силу)
│
└─ Изменения только в буфере
(не активны, не сохранены)
```
| Команда | Действие |
| ----------- | ------------------------------------------------------------------------- |
| **`apply`** | Применяет конфигурацию — изменения вступают в силу |
| **`save`** | Сохраняет конфигурацию в startup-config (переживёт перезагрузку) |
> **Важно:** в прошивке пилотного проекта (Урал) команда `apply` одновременно и применяла, и сохраняла конфигурацию в startup-config. В текущих (федеральных) прошивках это поведение изменено: `apply` только применяет, а для сохранения нужна отдельная команда `save`.
## 21.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) |
### 21.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин)
Как и на фильтре, балансировщик хранит **два раздела** прошивок — **A** и **B**:
| Раздел | Описание |
| ------ | ---------------------------------------------------------- |
| **A** | Первый раздел для прошивки |
| **B** | Второй раздел для прошивки |
Для каждого раздела отображается:
- **Активность** — активна эта прошивка или нет;
- **Версия** — номер версии прошивки;
- **Tries** — счётчик попыток загрузки.
Новая прошивка всегда устанавливается **вместо неактивной** в данный момент.
**Механизм автоматического rollback:**
Балансировщик отслеживает **количество неудачных попыток** загрузки с конкретной прошивки. Если устройство **более 3 раз подряд** не смогло загрузиться с определённой прошивки в течение приблизительно **20 минут**, эта прошивка считается **ненадёжной**, и балансировщик автоматически переключается на другой раздел.
> **Практический совет:** если вам нужно несколько раз перезагрузить балансировщик в короткий промежуток времени (например, для тестирования), помните о лимите в 3 перезагрузки. После третьей перезагрузки за короткий период прошивка будет признана нестабильной. Количество попыток и временной интервал **не настраиваются** — они зашиты в прошивке.
### 21.2.2. `call rdp firmware reset-tries`
Для сброса счётчика попыток загрузки используется команда:
```text
call rdp firmware reset-tries
```
Эта команда обнуляет значение **tries**, позволяя продолжить перезагрузки без риска автоматического переключения на другой раздел. В промышленной эксплуатации эта команда практически не требуется, но знать о ней полезно.
## 21.3. Настройка физических портов
Настройка физических портов — это **первый шаг** конфигурации балансировщика. Поскольку дефолтной конфигурации нет, все порты необходимо создавать вручную.
Для каждого порта задаются следующие параметры:
| Параметр | Описание |
| --------------- | ------------------------------------------------------------ |
| **Имя порта** | Произвольное имя (рекомендуется формат `P<порт><линия>`) |
| **number** | Номер физического интерфейса на лицевой панели (1–32) |
| **lane** | Номер линии внутри физического порта (0–3) |
| **speed** | Скорость порта: 10G, 25G или 100G |
| **mtu** | Максимальный размер кадра |
| **description** | Текстовое описание порта |
Пример конфигурации двух 10-гигабитных портов на одном физическом интерфейсе:
```text
set ports P21 number 2 lane 1 speed 10g
set ports P22 number 2 lane 2 speed 10g
```
### 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed)
Имя порта может быть **произвольным**, однако рекомендуется придерживаться единообразной схемы именования, отражающей номер физического порта и номер линии:
```text
P<номер_порта><номер_линии>
```
Например:
| Имя порта | Физический порт | Линия | Скорость | Описание |
| --------- | --------------- | ----- | -------- | ------------------------------------ |
| `P21` | 2 | 1 | 10G | Порт 2, линия 1 — первый 10G-канал |
| `P22` | 2 | 2 | 10G | Порт 2, линия 2 — второй 10G-канал |
| `P2` | 2 | — | 100G | Порт 2, все линии — 100G-канал |
### 21.3.2. 10G: указание lane (0–3), 100G: все lane задействованы
Поведение параметра **lane** зависит от выбранной скорости:
**При 10G (или 25G):**
Каждый физический порт QSFP28 содержит 4 линии. При использовании гидры (breakout-кабеля) каждая линия становится отдельным 10-гигабитным портом. Для каждого такого порта необходимо явно указать номер линии (`lane 0`, `lane 1`, `lane 2`, `lane 3`):
```text
set ports P20 number 2 lane 0 speed 10g
set ports P21 number 2 lane 1 speed 10g
set ports P22 number 2 lane 2 speed 10g
set ports P23 number 2 lane 3 speed 10g
```
В результате из одного физического QSFP28-разъёма получается **4 независимых порта** по 10 Гбит/с.
**При 100G:**
Все 4 линии объединены в один канал. Параметр `lane` **не указывается**, так как задействованы все линии:
```text
set ports P2 number 2 speed 100g
```
> **Рекомендация:** все физические порты настраиваются в соответствии со схемой организации связи на конкретной площадке. Единых «стандартных» настроек нет — конфигурация полностью зависит от того, какие устройства и на каких скоростях подключены к балансировщику.
## 21.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 P21 wan-port P22
set links link1 description "Bypass1-Mon0/Mon1"
```
| Параметр | Описание |
| ---------------- | ----------------------------------------------------------- |
| **Имя линка** | Произвольное название (рекомендуется единообразная схема) |
| **lan-port** | Порт в сторону абонентов (LAN) |
| **wan-port** | Порт в сторону интернета (WAN) |
| **description** | Описание — к какому байпасу и интерфейсу подключен линк |
> **Рекомендация:** в описании линка указывайте, к какому конкретно байпасу и к каким его интерфейсам подключён данный линк. Это значительно упрощает диагностику.
## 21.5. Настройка группы балансировки
После настройки портов и линков необходимо создать **группу балансировки** (balance group) и привязать к ней группы портов в сторону фильтров.
```text
Линки (оператор) Группа балансировки Фильтры
│ │ │
┌────┴────┐ ┌──────┴──────┐ ┌─────┴─────┐
│ link1 │ │ │ │ Filter │
│ link2 │──────► │ Balance │──────│ Group 1 │──► Фильтр 1
│ link3 │ Flow │ Group │ │ Group 2 │──► Фильтр 1
│ ... │ rules │ │ │ Group 3 │──► Фильтр 2
└─────────┘ └──────┬──────┘ │ ... │
│ └───────────┘
Профиль проверки
доступности
```
### 21.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-порт, смотрящие в сторону конкретной пары интерфейсов фильтра.
### 21.5.2. N_UNIT_QA: количество ядер фильтра минус один
Параметр **N_UNIT_QA** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика:
```text
set balance-group <имя_группы> n-unit-qa <число>
```
Значение **всегда равно общему количеству ядер процессора фильтра минус один**:
| Модель фильтра | Ядер всего | N_UNIT_QA |
| ----------------------------- | ---------- | --------- |
| Xeon 2695 (18 ядер) | 18 | 17 |
| Xeon 2699 (22 ядра) | 22 | 21 |
| Xeon Gold 6212 (24 ядра) | 24 | 23 |
Причина вычитания единицы: на фильтре **все ядра, кроме одного**, отданы под процесс EcoNAT, который обрабатывает трафик. Одно ядро — **сервисное**: на нём работает Linux, системные логи, управление. Оно не участвует в обработке трафика.
Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку.
## 21.6. Профиль проверки доступности (keep-alive)
К группе балансировки привязывается **профиль проверки доступности** (availability profile), определяющий параметры отправки keep-alive пакетов через группы портов в сторону фильтров.
```text
set balance-group <имя_группы> availability-profile <имя_профиля>
```
Профиль настраивается отдельно:
```text
set availability-profile <имя_профиля> <параметр> <значение>
```
### 21.6.1. Начальная задержка, интервал, порог потерь
| Параметр | Описание |
| -------------------------- | -------------------------------------------------------------------- |
| **Начальная задержка** | Время ожидания перед началом отправки keep-alive после поднятия интерфейсов (например, 1000 мс). Необходимо, чтобы фильтр успел полностью инициализировать интерфейсы |
| **Интервал** | Периодичность отправки keep-alive пакетов (например, 100 мс) |
| **Порог потерь (down)** | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5 пакетов) |
| **Порог восстановления (up)** | Количество последовательно полученных ответов, после которых неактивная filter group считается снова **активной** |
Механизм работы: балансировщик отправляет keep-alive пакет в LAN-порт filter group и ожидает получить его через парный WAN-порт. Время прохождения пакета (time of pass) измеряется в наносекундах и в нормальном состоянии составляет порядка **20–30 микросекунд**.
При потере заданного количества последовательных пакетов filter group переводится в состояние **bypass** — трафик не отправляется на фильтр, а перекладывается из одного порта в другой на уровне логики балансировщика.
### 21.6.2. Минимальное количество активных пар
Параметр **минимальное количество активных пар** (minimum active pairs) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной.
Пример: если задано значение 8, то группа балансировки будет считаться рабочей, пока хотя бы 8 filter groups активны — неважно, сколько их всего.
> **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, и балансировщик включал bypass на всех линках. Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко.
### 21.6.3. Перебалансировка: включение/выключение
Параметр **перебалансировки** (rebalancing) определяет, что происходит при выходе из строя одной из filter groups:
| Значение | Поведение |
| --------------- | ---------------------------------------------------------------------- |
| **Включена** | Трафик пересчитывается и распределяется по оставшимся filter groups |
| **Выключена** | Для упавшей filter group включается программный bypass, остальные работают без изменений |
**Перебалансировка** занимает определённое время и вычислительные ресурсы. При пересчёте хэша сессии могут попасть на **другие интерфейсы и другие фильтры**, что в общем случае может быть нежелательным (разрыв DPI-сессий, потеря контекста анализа).
> **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или разрыв всех сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную.
## 21.7. Настройка фильтров (Flow rules)
**Фильтры** (flow rules) на балансировщике — это правила, определяющие, что делать с трафиком, поступающим через линки. Каждое правило состоит из двух частей:
| Часть | Описание |
| ---------- | ----------------------------------------------------------- |
| **Match** | Условия, по которым отбирается трафик (заголовки пакетов) |
| **Action** | Действие с пакетом при совпадении |
### 21.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-условия можно использовать как для **включения** трафика в обработку, так и для **исключения** определённого трафика.
### 21.7.2. Actions: `balancing s_mac` → balance group / `bypass`
Действие (action) определяет, что происходит с пакетом при совпадении:
| Action | Описание |
| ----------------------- | ---------------------------------------------------------------- |
| **balancing s_mac** | Отправить трафик на группу балансировки. Балансировка выполняется по хэшу от source IP, destination IP и протокола |
| **bypass** | Пропустить трафик прозрачно — переложить из одного порта в другой, не отправляя на фильтры |
При использовании `balancing s_mac` дополнительно указывается **целевая группа балансировки**:
```text
set filters <имя_фильтра> flows <имя_правила> action balancing s_mac
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 s_mac
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
```
### 21.7.3. Приоритеты правил
Каждому правилу назначается **приоритет** (priority), определяющий порядок обработки. Пакет проверяется по правилам в порядке убывания приоритета — от **высшего** к **низшему**. Первое совпавшее правило определяет действие.
Типовая структура правил:
```text
Приоритет Правило Action
─────────────────────────────────────────────────────
100 VLAN 1 → на фильтр balancing s_mac
90 VLAN 2 → на фильтр balancing s_mac
80 VLAN 3 → на фильтр balancing s_mac
... ... ...
1 Всё остальное → bypass bypass
```
Правило с **самым низким приоритетом** и **без match-условий** (совпадает со всем) обычно задаёт action `bypass`. Это означает: всё, что не попало под предыдущие правила, пропускается прозрачно.
> **Применение для диагностики:** при траблшутинге можно создать правило с высоким приоритетом, которое перехватывает трафик конкретного VLAN и выполняет action `bypass`. Это позволяет исключить конкретный трафик из обработки фильтрами и проверить, влияет ли ТСПУ на проблему. По статистике правила (количество пакетов/байт) можно убедиться, что трафик действительно проходит через это правило.
### 21.7.4. Привязка фильтров к линкам
После настройки правил необходимо **привязать фильтр к линкам** — указать, на каких линках (в сторону оператора) данные правила будут действовать:
```text
set filters <имя_фильтра> links [ <линк1> <линк2> ... ]
```
Пример:
```text
set filters main links [ link1 link2 link3 link4 ]
```
Один набор правил (фильтр) может быть привязан к **нескольким линкам** одновременно. Все линки, привязанные к фильтру, используют одни и те же flow rules.
## 21.8. Настройка Heartbeat для GL Sun (пилотный проект)
Данная настройка актуальна **только для пилотного проекта на Урале**, где используются байпасы GL Sun. В федеральном проекте с байпасами Silicom эта настройка **не требуется** — Silicom самостоятельно генерирует и проверяет heartbeat-пакеты.
На Урале балансировщик работает в активном режиме и сам должен отправлять heartbeat-пакеты на байпас GL Sun:
| Параметр | Описание |
| --------------------------- | --------------------------------------------------------------- |
| **IPv4-адрес байпаса** | IP-адрес байпаса GL Sun |
| **Порт** | Порт для heartbeat-протокола |
| **Период отсылки** | Интервал отправки heartbeat (в наносекундах, например, 30 мкс) |
| **Группа балансировки** | Группа, для которой работает отправка heartbeat |
| **Список линков байпаса** | Идентификаторы сущностей на стороне байпаса GL Sun |
| **ToS** | Тип сервиса в IP-заголовке heartbeat-пакетов |
| **Автоматический возврат** | Возможность автоматического возврата трафика в режим primary при восстановлении группы балансировки |
Heartbeat-пакеты отправляются только при условии, что **группа балансировки находится в состоянии Active**. При переходе группы в неактивное состояние отправка прекращается, и связь с байпасом (по TCP) разрывается — состояние переходит в `disconnected`.
> **Примечание:** с байпасами Silicom логика работы другая — Silicom самостоятельно отсылает heartbeat и проверяет доступность интерфейсов, а балансировщик прозрачно пропускает эти пакеты между своими портами.
## 21.9. Management-интерфейс: IP, маска, default gateway
Настройка management-интерфейса балансировщика выполняется аналогично другим сетевым устройствам:
```text
set management ip <IP-адрес>
set management mask <маска_подсети>
set management default-gateway <IP-шлюза>
```
Management-интерфейс обеспечивает доступ к устройству по SSH и используется для управления, мониторинга и взаимодействия с ЦСУ.
> **Напоминание:** management Ethernet работает **только** на скорости 1 Гбит/с (см. [раздел 20.2](20.md)).
---
## Общий порядок настройки балансировщика
Для наглядности — последовательность настройки балансировщика «с нуля»:
```text
1. Установить прошивку
│
2. Настроить management-интерфейс
│
3. Настроить физические порты (ports)
│
4. Настроить линки (links) — пары LAN/WAN в сторону оператора
│
5. Настроить группу балансировки (balance group)
└── Создать filter groups (пары портов в сторону фильтров)
└── Задать N_UNIT_QA
└── Привязать профиль проверки доступности
│
6. Настроить профиль проверки доступности (availability profile)
│
7. Настроить фильтры (flow rules) — правила обработки трафика
└── Привязать фильтры к линкам
│
8. apply + save
```
---
[← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) · [Раздел 22: Балансировщик: мониторинг и диагностика →](22.md)
Reference in New Issue View Git Blame Copy Permalink