Max/DanielLavrushin_tspu-docs
1
0
Fork 0
mirror of https://github.com/DanielLavrushin/tspu-docs.git synced 2026-10-08 22:50:05 +03:00
Code Issues Packages Projects Releases Wiki Activity

Обновление документации: внесены изменения в главы 05, 06, 11, 20, 21, 22 и 24. Исправлены формулировки, уточнены технические детали, изменены параметры и описания для улучшения понимания работы системы. В частности, обновлены описания для MPLS-трафика, интерфейсов, параметров настройки фильтров и профилей Keep-Alive. Также добавлены пояснения по работе с сессиями и программным байпасом.

Browse Source
This commit is contained in:
Daniel Lavrushin
2026-09-23 20:00:05 +02:00
parent 73d1e3e642
commit aa7c3f3132
11 changed files with 283 additions and 227 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+7 -6
View File
@@ -50,6 +50,7 @@
- 4.3. Организация портов: пары LAN/WAN, линки
- 4.3.1. Принцип чётных/нечётных портов
- 4.3.2. Жёсткая привязка: трафик возвращается в тот же линк
- 4.3.3. Асимметричный трафик: все линки — на один балансировщик
- 4.4. Фильтры на балансировщике (Flow rules)
- 4.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация)
- 4.4.2. Отправка трафика на группу балансировки
@@ -304,18 +305,18 @@
- 21.2.2. `call rdp firmware reset-tries`
- 21.3. Настройка физических портов
- 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed)
- 21.3.2. 10G: указание lane (0–3), 100G: все lane задействованы
- 21.3.2. 10G: указание lane (1–4), 100G: все lane задействованы
- 21.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора)
- 21.5. Настройка группы балансировки
- 21.5.1. Привязка групп портов в сторону фильтров (filter groups)
- 21.5.2. N_UNIT_QA: количество ядер фильтра минус один
- 21.6. Профиль проверки доступности (keep-alive)
- 21.6.1. Начальная задержка, интервал, порог потерь
- 21.5.2. nat-unit-queues: количество ядер фильтра минус один
- 21.6. Профиль Keep-Alive (liveness profile)
- 21.6.1. Допустимая задержка, интервал, пороги потерь и восстановления
- 21.6.2. Минимальное количество активных пар
- 21.6.3. Перебалансировка: включение/выключение
- 21.7. Настройка фильтров (Flow rules)
- 21.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов
- 21.7.2. Actions: `balancing s_mac` → balance group / `bypass`
- 21.7.2. Actions: `balancing-as mag-hash` → balance group / `bypass`
- 21.7.3. Приоритеты правил
- 21.7.4. Привязка фильтров к линкам
- 21.8. Настройка Heartbeat для GL Sun (пилотный проект)
@@ -330,7 +331,7 @@
- 22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow
- 22.6. Состояние группы балансировки
- 22.6.1. Статус filter groups: up/bypass
- 22.6.2. Time of pass — время прохождения keep-alive пакета
- 22.6.2. time-on-path — время прохождения keep-alive пакета
- 22.7. Программный байпас: индивидуально для каждой группы портов
### [23. Распознавание протоколов (DPI Engine)](chapters/23.md)
chapters/02.md
+4 -4
View File
@@ -112,7 +112,7 @@ _Стык оператора: адреса и порты в прямом и об
Сегмент управления (VPN-шлюз, SPFS, СПХД)
```
В таком варианте **балансировщик не нужен**, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Порты байпаса Mon0 и Mon1 подключаются непосредственно к паре портов фильтра: Mon0 — к LAN-порту, Mon1 — к WAN-порту. Heartbeat-пакеты, которыми байпас проверяет канал до фильтра, в этой схеме доходят до фильтра; это не IP-пакеты, поэтому фильтр без обработки передаёт их в парный порт, и контур проверки замыкается.
В таком варианте **балансировщик не нужен**, поскольку весь трафик обрабатывается одним фильтром и распределение по нескольким фильтрам не требуется. Порты байпаса Mon0 и Mon1 подключаются непосредственно к паре портов фильтра: Mon0 — к LAN-порту, Mon1 — к WAN-порту. Heartbeat-пакеты, которыми байпас проверяет канал до фильтра, в этой схеме доходят до фильтра; это служебные кадры, которые фильтр без обработки передаёт в парный порт, и контур проверки замыкается.
Ограничения этой схемы: могут быть подключены только каналы **1 Гбит/с** или **10 Гбит/с** Ethernet, поскольку фильтры проекта (модели 2020/2040 и 4080/4120/4160 — [раздел 11](11.md)) не имеют интерфейсов 100 Гбит/с — только 1G и 10G в зависимости от конкретной модели; пропускная способность ограничена одним фильтром, а при его отказе байпас замыкает канал, и трафик проходит без анализа. По техническому описанию производителя 2024 года интерфейсы 100GE (2 × QSFP28) есть только у более поздней старшей модели EcoFilter 5200 (см. [указатель оборудования](../tspu-equipment/README.md)).
@@ -163,7 +163,7 @@ _Байпас: порты NET0/NET1 в сторону оператора, MON0/M
Все порты балансировщика делятся на две группы: порты, подключённые через байпасы к оборудованию оператора, и порты, к которым подключены фильтры; и те и другие организованы парами LAN/WAN. По умолчанию никакой конфигурации в балансировщике нет — номера и назначение портов выбираются при проектировании конкретного узла, поэтому номера портов в примерах условны.
На входе в балансировщик порты в сторону оператора объединяются в **линки** — логические пары LAN + WAN. Пакет, вошедший в LAN-порт линка, после обработки всегда выходит через WAN-порт того же линка (и наоборот) и ни в какой другой порт попасть не может. Так ТСПУ не меняет прохождение пакетов по каналам оператора: пакет, отправленный оператором в конкретный канал, выходит из ТСПУ в продолжение того же канала, и трафик разных линков никогда не смешивается. Соблюдается также правило проектирования: все каналы одного агрегированного линка (LAG) оператора заводятся на один и тот же балансировщик — иначе прямое и обратное направления одной сессии, разнесённые оператором по разным каналам агрегата, могут попасть на разные балансировщики и, следовательно, на разные фильтры.
На входе в балансировщик порты в сторону оператора объединяются в **линки** — логические пары LAN + WAN. Пакет, вошедший в LAN-порт линка, после обработки всегда выходит через WAN-порт того же линка (и наоборот) и ни в какой другой порт попасть не может. Так ТСПУ не меняет прохождение пакетов по каналам оператора: пакет, отправленный оператором в конкретный канал, выходит из ТСПУ в продолжение того же канала, и трафик разных линков никогда не смешивается. Соблюдается также правило проектирования: все каналы одного агрегированного линка (LAG) оператора заводятся на один и тот же балансировщик — иначе прямое и обратное направления одной сессии, разнесённые оператором по разным каналам агрегата, могут попасть на разные балансировщики и, следовательно, на разные фильтры ([раздел 4.3.3](04.md)).
К каждому линку привязаны **правила** (flow rules) балансировщика — они применяются в порядке приоритетов, и возможных действий два: отправить трафик в группу балансировки, то есть на фильтры, или прямо на входе вернуть его оператору через парный порт линка (действие bypass; не путать с устройством «байпас»). Возвращаются без анализа, как правило:
@@ -188,7 +188,7 @@ _Логика балансировщика: порты в сторону опе
Балансировщик разбирает стек заголовков (VLAN, MPLS и т. д.) и вычисляет хэш именно от IP-пакета, найденного под инкапсуляцией. Если IP-пакета в стеке нет, трафик пропускается прозрачно и на фильтры не отправляется.
При вычислении хэша учитывается также число обрабатывающих ядер фильтра (все ядра процессора, кроме одного сервисного, — параметр N_UNIT_QA), поэтому результат однозначно определяет не только пару портов, но и конкретное **ядро фильтра**, которое будет обрабатывать пакет, — трафик сразу равномерно распределяется по всем ядрам ([раздел 4.5.2](04.md), [21.5.2](21.md)). Балансировка выполняется аппаратно, программируемым чипом, и не логируется: узнать, на какой фильтр попала конкретная сессия, можно только поиском на фильтрах ([раздел 24.2](24.md)).
При вычислении хэша учитывается также число обрабатывающих ядер фильтра (все ядра процессора, кроме одного сервисного, — параметр `nat-unit-queues`), поэтому результат однозначно определяет не только пару портов, но и конкретное **ядро фильтра**, которое будет обрабатывать пакет, — трафик сразу равномерно распределяется по всем ядрам ([раздел 4.5.2](04.md), [21.5.2](21.md)). Балансировка выполняется аппаратно, программируемым чипом, и не логируется: узнать, на какой фильтр попала конкретная сессия, можно только поиском на фильтрах ([раздел 24.2](24.md)).
Для передачи информации о балансировке к пакету добавляется **дополнительный 4-байтовый заголовок** (по структуре похож на VLAN-тег, но таковым не является). Этот заголовок сообщает фильтру, на какое ядро направить пакет. После обработки фильтр возвращает пакет с тем же 4-байтовым заголовком, по нему балансировщик определяет, в какой именно операторский линк вернуть пакет, и снимает заголовок перед отправкой оператору. Так достигается корректное прохождение трафика: пакет, пришедший из конкретного порта оператора, возвращается в тот же порт независимо от того, каким фильтром он был обработан.
@@ -200,7 +200,7 @@ _Логика балансировщика: порты в сторону опе
Распределение детерминировано, пока состав группы не меняется; при включённой перебалансировке после отказа группы портов хэш пересчитывается, и часть сессий переезжает на другие фильтры ([раздел 4.6.3](04.md)). Обратная сторона принципа: одна сессия не может быть разбалансирована. Если, например, 200 Гбит/с трафика идут с одного адреса источника на один адрес назначения по одному протоколу, весь этот поток попадёт на один порт одного фильтра и даже на одно его ядро. Равномерная балансировка опирается на то, что в операторском трафике огромное количество разных сессий.
Отказоустойчивость на этом участке обеспечивает сам балансировщик — это второй, независимый от heartbeat байпаса (этап 1) контур контроля: в каждую пару портов в сторону фильтра он отправляет keep-alive-пакеты (через LAN-порт, с возвратом через WAN-порт), и если они перестают проходить — порт фильтра или сам фильтр перестал обрабатывать трафик, — трафик этой группы портов программно байпасится, то есть возвращается оператору без обработки, либо, в зависимости от настроек, перебалансируется на рабочие группы. В проекте перебалансировка отключена, и на время недоступности группы её трафик проходит без анализа. Подробнее — в [разделе 4.6](04.md).
Отказоустойчивость на этом участке обеспечивает сам балансировщик — это второй, независимый от heartbeat байпаса (этап 1) контур контроля: в каждую пару портов в сторону фильтра он отправляет keep-alive-пакеты (через LAN-порт, с возвратом через WAN-порт), и если они перестают проходить — порт фильтра или сам фильтр перестал обрабатывать трафик, — трафик этой группы портов программно байпасится, то есть возвращается оператору без обработки, либо, в зависимости от настроек, перебалансируется на рабочие группы. В проекте перебалансировку предполагается отключить — тогда на время недоступности группы её трафик проходит без анализа. Подробнее — в [разделе 4.6](04.md).
### Этап 4: Обработка на фильтре
chapters/03.md
+1 -1
View File
@@ -199,7 +199,7 @@
По документации Silicom heartbeat-пакеты по умолчанию отправляются каждые 5 мс, а окно контроля составляет 20 мс; оба параметра настраиваются: интервал от 3 мс до 10 с, окно контроля от 10 мс до 50 с.
Heartbeat-пакеты байпаса Silicom — это **не IP-пакеты**, а небольшие служебные Ethernet-кадры с не-IP типом; формат кадра задаётся в настройках байпаса. Формат по умолчанию — IPX; по запросу RDP.ru на устанавливаемых байпасах он заменяется на согласованный с разработчиком балансировщика вариант, прохождение которого проверялось на стендовых тестах. Поскольку это не IP-пакет, балансировщик не хэширует его и не отправляет на фильтры, а прозрачно передаёт в парный порт линка; в схеме без балансировщика ([раздел 2.3](02.md)) то же самое делает фильтр — не-IP-пакеты он пропускает в парный порт без обработки, и контур проверки замыкается на фильтре.
Heartbeat-пакеты байпаса Silicom — небольшие служебные Ethernet-кадры; формат кадра задаётся в настройках байпаса. По умолчанию это IPX-пакет, то есть не IP; по запросу RDP.ru на устанавливаемых байпасах формат заменяется на согласованный с разработчиком балансировщика вариант, прохождение которого проверялось на стендовых тестах. Балансировщик не отправляет такие кадры на фильтры, а прозрачно передаёт в парный порт линка; в схеме без балансировщика ([раздел 2.3](02.md)) их без обработки пропускает в парный порт фильтр, и контур проверки замыкается на фильтре.
Важно: при наличии балансировщика heartbeat-пакеты байпаса **не доходят до фильтров** — они заворачиваются обратно на уровне балансировщика. Таким образом, существуют **две независимые стадии** проверки отказоустойчивости:
chapters/04.md
+172 -124
View File
@@ -6,242 +6,290 @@
## 4.1. Назначение: распределение трафика по фильтрам
Балансировщик (EcoFilter Balancer) — это **высокопроизводительный программируемый коммутатор**, основная задача которого — принимать трафик от байпасов и **равномерно распределять** его по подключённым фильтрам для анализа и обработки.
Балансировщик (EcoFilter Balancer) — это **высокопроизводительный программируемый коммутатор**. Его основная задача — принимать трафик операторских каналов от байпасов и **равномерно распределять** его по подключённым фильтрам, а внутри каждого фильтра — по его процессорным ядрам. Для сети оператора балансировщик, как и остальное оборудование ТСПУ, прозрачен на уровне L2.
Помимо балансировки, балансировщик выполняет следующие функции:
- **фильтрация служебного трафика** — байпас (прозрачный пропуск) трафика, который не нужно отправлять на фильтры;
- **программный байпас** — возможность заворачивать трафик обратно к оператору, минуя фильтры;
- **контроль доступности фильтров** — отправка keep-alive пакетов и автоматическое отключение неисправных фильтров;
- **прозрачный пропуск heartbeat-пакетов** байпаса Silicom между своими портами.
- **согласование скоростей** — операторские каналы (как правило, 10G и 100G) распределяются по портам фильтров, которые в проекте в большинстве случаев подключаются интерфейсами 10G. Число фильтров определяется только объёмом трафика, поэтому число портов в сторону фильтров не совпадает с числом операторских каналов;
- **исключение служебного трафика** — возврат оператору без обработки трафика, который не нужно отправлять на фильтры (правила с действием bypass, [раздел 4.4](#44-фильтры-на-балансировщике-flow-rules));
- **контроль доступности фильтров** — отправка keep-alive-пакетов через каждую пару портов в сторону фильтров;
- **программный байпас** — вывод из обработки отдельной пары портов или всех фильтров сразу без флапа линков у оператора;
- **прозрачный пропуск heartbeat-пакетов** байпаса Silicom между парными портами линка ([раздел 3.4](03.md)).
Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. По умолчанию балансировщик поставляется **без конфигурации** — все порты, линки и правила необходимо создавать вручную при проектировании конкретного узла.
Балансировщик работает только с заголовками пакетов уровней L2–L4 и **ничего не знает** о том, что происходит на фильтрах: распознавание протоколов, DPI-листы и блокировки его не касаются. По документации производителя он поддерживает также прозрачный режим с зеркалированием: трафик пропускается мимо фильтров, а на фильтры отправляется только копия. В проекте фильтры в режиме копии трафика не используются; для вывода фильтров из обработки служит программный байпас ([раздел 4.6.2](#462-программный-байпас-при-потере-группы-портов)).
В ТСПУ тип А используется балансировщик **EcoFilter Balancer**; в эшелонированной системе (ТСПУ тип Б) на той же аппаратной платформе работает балансировщик с другим программным обеспечением — **Eco Highway** ([раздел 7](07.md)). Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. В простейшей конфигурации — один-два канала и один фильтр — балансировщик не нужен, и байпас подключается к фильтру напрямую ([раздел 2.3](02.md)).
С завода балансировщик поставляется с заводской (factory) прошивкой ограниченной функциональности и базовой версией рабочей прошивки, но **без рабочей конфигурации**. После установки нужной версии прошивки и настройки сегмента управления в конфигурации нет ни линков, ни групп балансировки, ни правил, а все используемые порты нужно настроить самостоятельно — всё это создаётся при проектировании конкретного узла ([раздел 21](21.md)).
## 4.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с
Балансировщик представляет собой компактное одноюнитовое (1U) устройство:
| Параметр | Значение |
| -------------------------- | --------------------------------------------------------------------------------- |
| **Форм-фактор** | 1U |
| **Порты** | 32 × QSFP28 |
| **Пропускная способность** | 3,2 Тбит/с; скорость провода обеспечивается на пакетах размером более 160 байт |
| **Скорости портов** | Платформа поддерживает 10/25/40/50/100GE (в зависимости от настроек и трансиверов); типовые скорости в проекте — 10G и 100G |
| **Питание** | 2 блока питания с горячим резервированием |
| **Передняя панель** | Консоль, порт управления Ethernet (работает только на 1 Гбит/с), USB, диагностический разъём |
| Параметр | Значение |
| -------------------------- | --------------------------------------- |
| **Форм-фактор** | 1U (одноюнитовый) |
| **Количество портов** | 32 порта QSFP28 |
| **Пропускная способность** | 3.2 Тбит/с (на пакетах > 160 байт) |
| **Скорости портов** | 10G / 25G / 100G |
| **Питание** | 2 блока питания, горячее резервирование |
| **Передняя панель** | Консоль, Management Ethernet (1G), USB |
Существуют также двухюнитовые балансировщики на 65 портов, но в проекте АСБИ используются **только одноюнитовые**. По техническому описанию производителя в основе балансировщика — P4-программируемый коммутатор; одноюнитовой 32-портовой модели соответствует платформа EcoSwitch 1032, в линейке есть также модель 2065 (2U, 65 × QSFP28, до 6,4 Тбит/с). Коммутационный чип платформы — Barefoot Tofino.
Существуют также двухюнитовые балансировщики (65 портов), но в проекте АСБИ используются **только одноюнитовые** модели.
Каждый порт QSFP28 состоит из четырёх линий (lane) по 25 Гбит/с. На скорости 100G задействованы все четыре линии; если настроить каждую линию отдельно на 10G, один физический порт даёт до четырёх портов 10G. Для их подключения используются **«гидры»** — breakout-кабели QSFP → 4 × SFP+, оптические или DAC.
Для подключения 10-гигабитных интерфейсов используются **гидры** (breakout-кабели): один порт QSFP28 разветвляется на четыре порта SFP+ (10G) с помощью оптических или DAC-кабелей. Таким образом, один физический QSFP28-порт может предоставить до четырёх 10G-портов.
При работе на скорости 100G все четыре линии (lane) физического порта объединяются и работают совместно.
Внутри чипа Tofino — два независимых конвейера (pipeline) со своими ресурсами, каждый обслуживает свою половину портов. На EcoFilter Balancer оба конвейера настроены одинаково, поэтому к какому из них относится порт, значения не имеет — в отличие от Eco Highway ([раздел 7.4](07.md)). Подробно аппаратная часть описана в [разделе 20](20.md).
## 4.3. Организация портов: пары LAN/WAN, линки
Все порты балансировщика логически делятся на две группы:
- **Порты в сторону оператора** (через байпасы) — подключены к каналам связи оператора;
- **Порты в сторону фильтров** — подключены к фильтрам для передачи трафика на обработку.
- **порты в сторону оператора** — подключены через байпасы к каналам связи оператора;
- **порты в сторону фильтров** — подключены к фильтрам.
Порты внутри каждой группы объединяются в **пары** 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
Оборудование оператора (через байпасы)
│ │ │ │
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
Оборудование оператора (через байпасы)
│ │ │ │
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
```
### 4.3.1. Принцип чётных/нечётных портов
По договорённости, принятой при проектировании, на балансировщике соблюдается тот же принцип, что и на фильтрах:
На фильтрах разделение портов жёсткое: в каждой паре чётный порт — LAN, нечётный — WAN ([раздел 11.5](11.md)). На балансировщике жёсткой привязки нет — порт становится LAN или WAN только при настройке линка или filter group. Для однозначности при проектировании принят тот же принцип, что и на фильтрах:
- **Чётные** порты — **LAN** (в сторону абонентов);
- **Нечётные** порты — **WAN** (в сторону интернета).
- **чётные** порты — **LAN** (в сторону абонентов);
- **нечётные** порты — **WAN** (в сторону интернета).
Например: порт P42 (чётный) — LAN-порт, парный ему P41 (нечётный) — WAN-порт. Для 100-гигабитных портов, у которых нет второй цифры (номера линии), определяющей является единственная цифра: P10 (чётный) — LAN, P9 (нечётный) — WAN.
Этот принцип распространяется как на порты в сторону операторского оборудования, так и на порты в сторону фильтров.
Для 10-гигабитных портов чётность определяется по номеру линии: p4-2 — LAN, парный ему p4-1 — WAN. У 100-гигабитных портов номера линии нет, и определяющим является номер порта: p10 — LAN, p9 — WAN. Принцип действует как для портов в сторону операторского оборудования, так и для портов в сторону фильтров. На балансировщике Eco Highway он не соблюдается: там LAN- и WAN-порты разнесены по разным конвейерам ([раздел 7.4.1](07.md)).
### 4.3.2. Жёсткая привязка: трафик возвращается в тот же линк
Трафик, пришедший через конкретный порт оператора, **обязательно возвращается** через парный порт того же линка. Пакет, вошедший через P42 (LAN), после обработки выйдет только через P41 (WAN) — и никуда больше. Аналогично, пакет из P41 вернётся только в P42.
Пакет, вошедший в LAN-порт линка, после обработки выходит только через WAN-порт того же линка, и наоборот: вошедший через p4-2 выйдет только через p4-1, вошедший через p4-1 — только через p4-2. Ни в какой другой порт пакет попасть не может — это сделано специально, чтобы пакеты разных линков никогда не смешивались.
Это фундаментальное правило обеспечивает **прозрачность ТСПУ** для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его обратно в тот же канал, независимо от того, каким фильтром пакет был обработан.
Это правило обеспечивает **прозрачность ТСПУ** для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его в продолжение того же канала, независимо от того, каким фильтром пакет был обработан. Механизм — служебный 4-байтный заголовок, по которому балансировщик узнаёт исходный линк вернувшегося от фильтра пакета ([раздел 4.5.3](#453-дополнительный-4-байтный-заголовок-для-фильтров)).
Механизм реализации: при балансировке к пакету добавляется 4-байтовый заголовок, который, помимо информации о ядре фильтра, содержит идентификатор исходного линка. Когда фильтр возвращает обработанный пакет с этим заголовком, балансировщик по нему определяет, в какой операторский линк вернуть пакет.
### 4.3.3. Асимметричный трафик: все линки — на один балансировщик
Оба направления каждого потока должны попадать на один и тот же фильтр и одно его ядро; проще всего это обеспечить, когда оба направления проходят через один и тот же балансировщик. Поэтому на один балансировщик заводятся все линки, по которым могут идти прямое и обратное направления одного и того же трафика. В частности, все каналы одного агрегированного линка (LAG) оператора приходят на один балансировщик: оборудование оператора с каждой стороны распределяет потоки по каналам агрегата своим хэшем, и прямое и обратное направления одной сессии могут оказаться в разных каналах. Поэтому при проектировании узла у оператора выясняют, какие каналы входят в агрегаты.
Речь идёт о случае, когда оба направления проходят через ТСПУ, но по разным каналам. Если одно из направлений вообще минует ТСПУ, тип А такой трафик обработать не может — для этого предназначена эшелонированная система ([раздел 7.2](07.md)).
Если одного балансировщика недостаточно, применяется перекрёстная (кроссированная) схема с несколькими балансировщиками, к которым подключены одни и те же фильтры. Чтобы поток попадал на один и тот же фильтр и одно ядро, на какой бы балансировщик он ни пришёл, группы балансировки на всех балансировщиках такой схемы настраиваются одинаково — те же фильтры в том же порядке, то же число ядер; в новых версиях ПО для сверки предусмотрена контрольная сумма конфигурации группы балансировки (`show ecofilter-balancer balancing-config-hash`). В эшелонированной системе такая схема может не подойти, поскольку фильтры там подключаются по схеме on-a-stick ([раздел 7.3.3](07.md)).
## 4.4. Фильтры на балансировщике (Flow rules)
Перед отправкой трафика на фильтры балансировщик пропускает каждый пакет через **правила фильтрации** (flow rules). Каждое правило состоит из двух частей:
> **Примечание о версиях ПО.** Имена параметров в этой главе — группы балансировки (`balance-groups`) с парами портов `filter-group`, наборы правил `filters` с привязкой `apply-to-links`, действие `balancing-as mag-hash` с `to-balance-group`, параметры `nat-unit-queues` и `rebalance` — относятся к ранней модели конфигурации балансировщика, по которой построен и [раздел 21](21.md). В новых версиях ПО модель другая: группа балансировки задаётся как `ecofilter-balancer ecofilter-unit` с парами портов `pair` и числом ядер `cores`, правила — как `ecofilter-balancer flow` с действиями `bypass` (по умолчанию), `drop` и `to-ecofilter`, а метод хэширования — одним параметром для всего устройства (`ecofilter-balancer balancing-method`). Логика работы при этом та же.
- **Match** — условие совпадения (по каким критериям определять трафик);
- **Action** — действие (что делать с совпавшим трафиком).
Термин «фильтр» на балансировщике означает не устройство, а **именованный набор правил**, который привязывается к линкам в сторону оператора (параметр `apply-to-links`). Каждое правило (flow) состоит из трёх частей:
Правила привязываются к **линкам** в сторону оператора и обрабатываются в порядке **приоритетов**.
- **match** — условия совпадения;
- **action** — действие с совпавшим пакетом;
- **priority** — приоритет: правила проверяются в порядке приоритета, от высшего к низшему, и срабатывает первое совпавшее. Направление шкалы — больше или меньше число означает более высокий приоритет — в документации производителя описано противоречиво, поэтому его стоит проверять на используемой версии ПО.
Действий в ТСПУ тип А два: отправить трафик на группу балансировки, то есть на фильтры, или вернуть его оператору без обработки (bypass). В документации производителя для новых версий ПО описаны также действие `drop` и блокировка по таблицам, загружаемым с внешнего gRPC-сервера (`external-acl`, действие `block`). В рассматриваемой схеме ТСПУ тип А блокировку выполняют фильтры, а балансировщик трафик не блокирует — в отличие от эшелонированной системы ([раздел 7](07.md)).
Правила можно строить двумя способами: перечислить трафик-исключения с действием bypass, а всё остальное отправить на фильтры, — либо, наоборот, перечислить трафик, который нужно отправить на фильтры, а всё остальное вернуть оператору завершающим правилом. Обычно правил на балансировщике ТСПУ тип А немного, они задаются вручную и описывают исключения — например, служебный VLAN возвращается оператору, а весь остальной трафик отправляется на фильтры. На Eco Highway, наоборот, правила загружаются из ЦСУ и исчисляются десятками и сотнями тысяч ([раздел 7.3.1](07.md)). По каждому правилу балансировщик считает пакеты и байты; эта статистика используется при диагностике ([разделы 22.5](22.md) и [24.4](24.md)).
### 4.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация)
Действие `action bypass` позволяет указать, что совпавший трафик должен быть **немедленно возвращён** в сторону оператора, минуя фильтры. Это используется для служебного трафика:
Действие **bypass** возвращает совпавший трафик оператору через парный порт линка сразу на входе, не отправляя его на фильтры. Так поступают с трафиком, который не нужно и нежелательно анализировать:
- **BGP** (TCP-порт 179) — протоколы маршрутизации;
- **Мультикаст-трафик** — групповые рассылки;
- **Другие служебные протоколы**, которые нежелательно пропускать через DPI.
- протоколы маршрутизации и сигнализации — например, BGP (TCP-порт 179);
- мультикаст-трафик;
- служебный трафик оператора, выделенный в отдельный VLAN;
- прочий трафик, анализ которого не требуется.
С таким трафиком на фильтрах ничего плохого не произойдёт (он будет прозрачно пропущен), но лучше его не трогать — это снижает нагрузку на фильтры и исключает потенциальное влияние.
С таким трафиком на фильтрах ничего плохого произойти не должно, но лучше его не трогать: фильтровать в нём нечего, а служебные протоколы чувствительны к задержкам и потерям. Кроме того, это разгружает фильтры.
Типичная конфигурация: все правила для конкретного трафика задаются с высоким приоритетом и действием `bypass`, а в самом конце ставится правило-«заглушка» с самым низким приоритетом, без условий совпадения и с действием `bypass`. Таким образом, **всё, что не попало** под явные правила отправки на фильтры, **байпасится**.
Если правила построены по второму способу, набор завершается правилом с самым низким приоритетом, пустым условием (совпадает всё) и действием bypass: весь трафик, не попавший под предыдущие правила, возвращается оператору без обработки. Тогда на фильтры попадает только трафик, явно отобранный правилами, а всё, что правилами не перечислено, остаётся без фильтрации.
Отбором по VLAN пользуются и при подключении BRAS или CGNAT по схеме on-a-stick: на фильтры отправляют только VLAN одного направления, чтобы каждая сессия обрабатывалась один раз ([раздел 6.4.2](06.md)).
### 4.4.2. Отправка трафика на группу балансировки
Действие `action balancing s_mac` отправляет совпавший трафик в указанную **группу балансировки** (balance group) для распределения по фильтрам. Параметр `s_mac` означает балансировку по source IP, destination IP и протоколу.
Действие балансировки задаётся как `balancing-as mag-hash` — распределение по хэшу от адресов источника, назначения и IP-протокола — вместе с целевой группой (`to-balance-group`): групп балансировки может быть несколько, и правило определяет, в какую из них отправить трафик. В новых версиях ПО этому соответствует действие `to-ecofilter`, а метод хэширования задаётся отдельно для всего устройства ([раздел 4.5.1](#451-хэш-сумма-source-ip--destination-ip--протокол)).
Пример правила: «все пакеты с VLAN ID = 1 отправить на группу балансировки `group_filter`». Трафик конкретного VLAN будет обработан фильтрами, а весь остальной трафик, не попавший под это правило, — байпасится.
Пример: правило с условием «первый VLAN-тег равен 1» и действием балансировки отправляет трафик VLAN 1 на фильтры, а завершающее правило bypass возвращает оператору всё остальное.
Условия совпадения (match) могут включать:
Условия совпадения (match) — по документации производителя; имена условий приведены для текущих версий ПО:
| Критерий | Описание |
| ----------------- | -------------------------------------- |
| **VLAN ID** | Номер VLAN-тега (один или несколько) |
| **IPv4 src/dst** | Адрес или подсеть источника/назначения |
| **L4 port** | Порт TCP/UDP |
| **MAC-адрес** | Source или destination MAC |
| **MPLS** | Количество MPLS-меток |
| **Глубина тегов** | Количество VLAN-тегов в пакете |
| Критерий | Описание |
| --------------- | -------------------------------------------------------------------------------------------- |
| **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-подсеть). Матчить можно как для включения трафика в обработку, так и наоборот — для исключения.
В одном правиле можно комбинировать несколько условий, например VLAN и IPv4-подсеть. Настройка правил описана в [разделе 21.7](21.md).
## 4.5. Балансировка трафика
### 4.5.1. Хэш-сумма: source IP + destination IP + протокол
Балансировка трафика по фильтрам выполняется на основе **хэш-суммы**, вычисляемой по трём параметрам IP-пакета:
Трафик распределяется по filter groups на основе **хэш-суммы** от трёх полей IP-пакета:
1. **Source IP** — адрес источника;
2. **Destination IP** — адрес назначения;
3. **IP-протокол** — номер протокола (TCP, UDP и т.д.).
3. **IP-протокол** — номер протокола (TCP, UDP и т. д.).
Для вычисления хэша балансировщик разбирает стек заголовков инкапсуляции (VLAN-теги, MPLS-метки) и добирается до IP-заголовка. Если IP-пакет не обнаружен, трафик **прозрачно пропускается** (байпасится), не отправляясь на фильтры.
В новых версиях ПО метод хэширования задаётся для всего устройства параметром `ecofilter-balancer balancing-method`; описанной схеме соответствует метод `layer-3`, он же используется по умолчанию, а в качестве хэш-функции производитель указывает CRC32. Доступны и другие методы — только по адресу назначения (`dst-ip`) и с добавлением портов TCP/UDP (`layer-4`), — но в ТСПУ используется балансировка по адресам и протоколу.
Балансировка работает эффективно за счёт **огромного количества сессий** в реальном операторском трафике. Произведение количества source IP × destination IP × протоколов даёт число, достаточное для равномерного распределения по всем фильтрам и ядрам. Однако одну единственную сессию (один source IP, один destination IP, один протокол) **разбалансировать невозможно** — весь её трафик попадёт на один фильтр и одно ядро.
Для вычисления хэша балансировщик разбирает стек инкапсуляции и добирается до IP-заголовка ([раздел 4.7](#47-работа-с-различными-инкапсуляциями-vlan-mpls)). Если IP-пакет не найден, трафик пропускается прозрачно и на фильтры не отправляется.
Балансировка работает за счёт **огромного количества** разных сочетаний «адрес источника — адрес назначения — протокол», реально встречающихся в операторском трафике: когда таких сочетаний много и ни одно из них не несёт заметной доли трафика, хэш распределяет нагрузку по всем filter groups и ядрам достаточно равномерно.
Обратная сторона: порты TCP/UDP в хэш не входят, поэтому **весь трафик между одной парой адресов по одному протоколу** — сколько бы соединений в нём ни было — попадает на одну пару портов одного фильтра и на одно его ядро. Разбалансировать такой поток невозможно: если, например, 200 Гбит/с идут с одного адреса на один адрес по одному протоколу, весь этот трафик будет направлен в одну пару портов и на одно ядро одного фильтра — и в пару портов 10G он физически не поместится. Это стоит учитывать для адресов, за которыми стоит много абонентов, — например, при установке ТСПУ после CGNAT ([раздел 6.3](06.md)): трафик многих абонентов с одного внешнего адреса к одному и тому же ресурсу (узлу CDN, кэш-серверу, популярному сервису) попадает на одно ядро.
### 4.5.2. Учёт количества ядер фильтров
Параметр **N_UNIT_QA** на балансировщике задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение **всегда равно общему количеству ядер процессора фильтра минус один**, поскольку одно ядро является сервисным — на нём работает ОС Linux, системные логи, управление. Все остальные ядра отданы процессу EcoNAT для обработки трафика.
Параметр **`nat-unit-queues`** задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение **всегда равно общему количеству ядер процессора фильтра минус один**: все ядра, кроме одного, отданы процессу EcoNAT, обрабатывающему трафик, а одно ядро сервисное — на нём работают Linux, системные логи и управление.
Параметр N_UNIT_QA **напрямую влияет** на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между **ядрами** каждого фильтра.
Параметр **напрямую влияет** на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между **ядрами** каждого фильтра. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр `cores`, по умолчанию 1 — поэтому значение нужно задавать явно). Настройка — в [разделе 21.5.2](21.md).
### 4.5.3. Дополнительный 4-байтный заголовок для фильтров
В точке балансировки к пакету добавляется **дополнительный 4-байтовый заголовок**. По структуре он похож на VLAN-тег, но VLAN-тегом не является. Этот заголовок выполняет две функции:
В точке балансировки к пакету добавляется **дополнительный 4-байтный заголовок**. По структуре он похож на VLAN-тег, но VLAN-тегом не является. Заголовок выполняет две функции:
1. **Для фильтра** — сообщает, на какое ядро направить данный пакет для обработки;
2. **Для балансировщика** — при возврате обработанного пакета от фильтра определяет, в какой операторский линк вернуть пакет.
1. **Для фильтра** — сообщает, на какое ядро направить пакет для обработки;
2. **Для балансировщика** — при возврате обработанного пакета от фильтра указывает, в какой операторский линк его вернуть.
Фильтр после обработки возвращает пакет **с тем же 4-байтовым заголовком**. Балансировщик считывает заголовок, определяет исходный линк, удаляет заголовок и отправляет пакет обратно оператору.
Фильтр возвращает пакет **с тем же 4-байтным заголовком**. Балансировщик считывает заголовок, определяет исходный линк, удаляет заголовок и отправляет пакет обратно оператору.
В эшелонированной системе вместо этого заголовка используется VLAN-тег: балансировщик Eco Highway помечает им трафик, а фильтр после обработки меняет его на другой ([раздел 7.3.3](07.md)).
Из-за 4-байтного заголовка кадры на участке между балансировщиком и фильтром на 4 байта длиннее исходных: максимальный кадр оператора вместе с заголовком должен укладываться в MTU портов балансировщика в сторону фильтров и в L2 MTU фильтра, иначе крупные кадры будут отбрасываться. В проекте на портах балансировщика выставляется MTU около 9000 байт (по умолчанию 9000, платформа допускает до 10240), а на фильтрах — L2 MTU 9216 ([раздел 15.2.4](15.md)); если оператор использует кадры крупнее, MTU нужно согласовать при проектировании.
### 4.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро
Хэш-функция балансировщика **симметрична**: при вычислении хэша для обратного пакета (от интернета к абоненту) source и destination IP меняются местами, но итоговая хэш-сумма совпадает с прямым пакетом.
Хэш вычисляется **симметрично**: у обратного пакета (от интернета к абоненту) адреса источника и назначения поменялись местами, но итоговое значение совпадает со значением для прямого пакета. Сама функция CRC32 несимметрична, так что симметрию обеспечивает способ формирования входных данных хэша.
Это гарантирует:
- оба направления одной сессии **всегда попадают на один и тот же фильтр**;
- более того — на одно и то же **ядро** этого фильтра;
- более того — на одно и то же **ядро** этого фильтра, а если оба направления проходят через один балансировщик, — и на одну и ту же пару портов;
- сессия **никогда не распределяется** по разным фильтрам.
Благодаря этому фильтр всегда видит полную картину сессии (и запрос, и ответ), что критически важно для корректной работы DPI-анализа. Сессию любого абонента можно найти на одном конкретном фильтре.
Благодаря этому фильтр всегда видит полную картину сессии — и запрос, и ответ, — что необходимо для корректного распознавания трафика и применения политик. Распределение детерминировано, пока состав группы балансировки не меняется ([раздел 4.6.3](#463-перебалансировка-трафика-опционально)).
Важно: балансировщик **не ведёт логов** о том, куда отправил конкретный пакет — вся обработка происходит на аппаратном уровне. Чтобы найти, на каком фильтре «приземлилась» конкретная сессия, необходимо **обойти все фильтры** площадки. При 2–3 фильтрах это делается вручную; при большем количестве (до 15) — автоматизируется скриптом.
Балансировщик **не ведёт логов** о том, куда отправлен конкретный пакет: балансировка выполняется аппаратно, программируемым чипом, на скорости провода. Чтобы найти, на каком фильтре обслуживается сессия абонента, нужно обойти фильтры площадки — вручную, если их два-три, или простым скриптом, если их много (на некоторых площадках — около полутора десятков); скрипт справляется примерно за десяток секунд ([раздел 24.2](24.md)).
## 4.6. Отказоустойчивость
### 4.6.1. Keep-alive пакеты к фильтрам
Балансировщик непрерывно контролирует доступность фильтров, отправляя **keep-alive пакеты** через каждую пару портов (filter group) в сторону фильтров.
Балансировщик непрерывно проверяет каждую filter group **keep-alive-пакетами**. С байпасами Silicom это второй, независимый от heartbeat байпаса контур контроля: heartbeat байпаса проверяет канал до балансировщика и дальше него не проходит, а keep-alive балансировщика — путь до фильтра и обратно ([раздел 3.4](03.md)).
Принцип работы:
1. Балансировщик отправляет keep-alive через **LAN-порт** filter group;
2. Пакет проходит через фильтр (заворачивается на первой проверке, т.к. не является IP-пакетом);
3. Пакет возвращается через парный **WAN-порт**;
4. Балансировщик фиксирует **время прохождения** (time of pass) — в штатном режиме порядка 27 микросекунд.
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 мкс ([раздел 22.6.2](22.md)).
Параметры keep-alive настраиваются в **профиле проверки доступности** (availability profile):
На фильтре принятые keep-alive-пакеты учитываются счётчиком `cr_pass_ecobalancer_keepalive` — по нему можно убедиться, что пакеты балансировщика до фильтра доходят.
| Параметр | Описание |
| -------------------------------- | -------------------------------------------------------------------- |
| **Начальная задержка** | Время ожидания после старта перед началом отправки |
| **Интервал** | Периодичность отправки (типично ~100 мс) |
| **Порог потерь** | Число потерянных пакетов для признания группы неактивной (типично 5) |
| **Порог восстановления** | Число успешных пакетов для восстановления активности |
| **Мин. количество активных пар** | Порог, ниже которого вся balance group считается неактивной |
Keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик: даже первую проверку («IP-пакет или нет») выполняет процессор фильтра, поэтому если фильтр завис или перегружен настолько, что не пропускает пакеты, keep-alive не вернётся. Оценивать загрузку фильтра — не основная задача keep-alive, однако сильно перегруженный фильтр — например, при загрузке таблиц сессий заметно выше рекомендованных 20 % — теоретически может начать терять и их ([раздел 22.6](22.md)).
Keep-alive пакеты проверяют не только физическую доступность канала, но и **работоспособность фильтра** в целом: если «мозг» фильтра завис или перегружен настолько, что не может обрабатывать даже не-IP-пакеты, keep-alive не вернётся, и балансировщик это обнаружит.
Параметры проверки задаются в **профиле 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, и вся площадка уходила в аппаратный байпас с флапом линков у оператора ([раздел 3.3.1](03.md)). Такое значение не обязательно — порог можно задать гибче.
### 4.6.2. Программный байпас при потере группы портов
При потере keep-alive пакетов для конкретной filter group балансировщик переводит эту группу в состояние **программного байпаса**: трафик, предназначенный для данной пары портов, **не отправляется на фильтр**, а заворачивается обратно с LAN-порта на WAN-порт (и наоборот) непосредственно на балансировщике.
При потере keep-alive для конкретной filter group балансировщик переводит эту пару портов в **программный байпас**: трафик, который по хэшу приходится на неё, не отправляется на фильтр, а сразу перекладывается с входного порта линка на парный и возвращается оператору.
Ключевые особенности:
- Программный байпас применяется **индивидуально** к каждой filter group — остальные группы продолжают работать;
- Переключение **не вызывает флапов** линков оператора — оператор ничего не заметит;
- Единственное последствие — часть трафика временно перестаёт фильтроваться;
- При восстановлении доступности фильтра группа **автоматически возвращается** в активное состояние.
- программный байпас применяется **индивидуально** к каждой filter group — остальные пары продолжают работать;
- переключение **не вызывает флапов** линков оператора — оператор ничего не замечает;
- основное последствие — часть трафика временно не фильтруется; кроме того, возможны кратковременные потери пакетов — пока неисправность ещё не обнаружена и в момент переключения, а после возврата пары в работу сессии, открытые во время байпаса, приходят на фильтр «с середины»;
- когда keep-alive снова начинают проходить, пара **автоматически возвращается** в работу (если перебалансировка выключена);
- о переключении балансировщик пишет в журнал. В стандартный набор SNMP-трапов (перезагрузка, авторизация, состояние физических портов, блоки питания) такое событие не входит; в новых версиях ПО трап на изменение состояния можно настроить отдельно (условие `xpath`). Так система мониторинга узнаёт о проблеме, и её можно устранить.
Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса приводила к переключению **всей площадки** на байпас с флапами линков у оператора.
Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса переводила **всю площадку** в аппаратный байпас с флапом линков у оператора ([раздел 4.6.1](#461-keep-alive-пакеты-к-фильтрам)), а возврат в работу требовал повторного флапа.
Программный байпас можно также включить **вручную** — для диагностики или при проведении технических работ. Существует возможность перевести все фильтры в режим программного байпаса одной командой, полностью исключив ТСПУ из обработки трафика без влияния на оператора.
Программный байпас можно включить и **вручную** — для диагностики или на время технических работ. Вручную переключается группа балансировки целиком: в новых версиях ПО это команда `call ecofilter-balancer set-bypass-ecofilter-unit` с режимами auto (штатная работа: трафик идёт на фильтры, пока группа активна), bypass (весь трафик группы идёт мимо фильтров) и primary (трафик принудительно направляется на фильтры) ([раздел 22.7](22.md)); команды ручного переключения перенесены в EcoFilter Balancer из программного байпаса Eco Highway. Так можно одной командой исключить ТСПУ из обработки трафика без какого-либо влияния на линки оператора; такой режим применялся при испытаниях эшелонированной системы.
Если фильтр перегружен и теряет keep-alive, filter group может периодически переключаться между работой и программным байпасом. Физических флапов у оператора это не вызывает, но при каждом переключении теряется небольшое количество пакетов ([раздел 22.6](22.md)). Чтобы перегрузку заметить раньше, система мониторинга должна отслеживать загрузку таблиц на фильтрах и срабатывать на превышение оптимального значения.
### 4.6.3. Перебалансировка трафика (опционально)
Альтернативой программному байпасу является **перебалансировка** трафика на оставшиеся рабочие filter group. Эта возможность настраивается в профиле проверки доступности, но, как правило, **отключена** по следующим причинам:
Альтернатива программному байпасу — **перебалансировка** (параметр группы балансировки `rebalance`): трафик пропавшей filter group перераспределяется по оставшимся рабочим парам портов. В примерах конфигурации перебалансировка включена, но в проекте её планируется **выключить**, поскольку:
- Перебалансировка **занимает время** и вычислительные ресурсы;
- Происходит **пересчёт хэша** для всех сессий — сессии могут попасть на другие фильтры;
- Существующие сессии на «старых» фильтрах **разрываются** (фильтр теряет контекст сессии);
- В общем случае это может быть **нежелательно**.
- перебалансировка занимает время и вычислительные ресурсы;
- хэш пересчитывается для всех сессий, и сессии могут перейти на другие пары портов и другие фильтры;
- новый фильтр видит такие сессии «с середины», без начального обмена, а контекст анализа на прежнем фильтре теряется; чтобы такие сессии вообще заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN ([раздел 15.2.6](15.md)).
Рекомендуемый подход для федерального проекта: программный байпас на уровне отдельной filter group без перебалансировки. Часть трафика временно не фильтруется — это меньшее зло, чем перерыв в работе всей площадки или разрыв всех сессий.
Производитель описывает этот режим как резервирование N+X: неисправный фильтр исключается из группы балансировки, его потоки перераспределяются между исправными, а при выходе из строя всех фильтров срабатывает режим bypass. В проекте резервирование фильтров по схеме N+1 не предусмотрено: число фильтров рассчитывается так, чтобы пропустить трафик оператора в худшем сценарии; допустим ли при этом выход из строя одного фильтра, определяется расчётом мощностей конкретной площадки ([раздел 1.4](01.md)).
Рекомендуемый подход для федерального проекта — программный байпас на уровне отдельной filter group без перебалансировки. Часть трафика временно не фильтруется, но это меньшее зло, чем флап линков оператора или массовый переезд сессий.
## 4.7. Работа с различными инкапсуляциями (VLAN, MPLS)
Балансировщик **не снимает и не модифицирует** никакие теги, метки и заголовки инкапсуляции. Вся обработка ограничивается **чтением** заголовков:
Балансировщик **не снимает и не модифицирует** теги, метки и другие заголовки инкапсуляции — он только читает их, чтобы добраться до IP-заголовка. По документации производителя балансировщик разбирает:
- **VLAN-теги** — могут использоваться в условиях match для правил фильтрации (например, байпас служебного VLAN);
- **MPLS-метки** — балансировщик может определить их наличие и количество, но матчить по конкретным значениям MPLS-меток не имеет практического смысла;
- **QinQ** (двойные VLAN-теги) — поддерживается чтение с учётом глубины тегов.
- до трёх VLAN-тегов (802.1Q, QinQ);
- до шести MPLS-меток;
- PPPoE;
- туннели GRE и IP-in-IP —
Для вычисления хэша балансировщик **разбирает весь стек** инкапсуляции и добирается до IP-заголовка. Это облегчает работу фильтра, у которого ограничения на типы инкапсуляции несколько строже.
и находит в них пакеты IPv4 и IPv6.
Пакет передаётся на фильтр **в неизменном виде** (с добавлением только 4-байтового заголовка балансировки). Все VLAN-теги, MPLS-метки и прочие заголовки сохраняются.
Заголовки инкапсуляции можно использовать в условиях правил: значения VLAN-тегов и их число, число MPLS-меток ([раздел 4.4.2](#442-отправка-трафика-на-группу-балансировки)). Отбора по значениям MPLS-меток среди условий нет, да он и не был бы надёжным: значения меток на линке назначает соседний маршрутизатор оператора (при LDP и RSVP-TE — динамически), и они могут меняться при перестроении LSP.
Балансировщик сам разбирает сложную инкапсуляцию — множество тегов и меток — и сам выбирает ядро фильтра, сообщая его в 4-байтном заголовке, поэтому распределять такой трафик по ядрам фильтру не нужно. Это облегчает работу фильтра, у которого ограничений на типы инкапсуляции и их балансировку больше. Разбирать заголовки для анализа фильтр всё равно должен сам и работает только с IP-пакетом; глубина разбора VLAN-тегов на фильтре задаётся параметром VLAN Mode ([раздел 15.2.1](15.md)).
На фильтр пакет уходит с исходным стеком заголовков и добавленным 4-байтным заголовком балансировки, а обратно оператору — с тем же стеком, с каким пришёл. Кадры, в которых IP-пакет не найден, на фильтры не отправляются и прозрачно передаются в парный порт линка. Heartbeat-пакеты байпаса Silicom также до фильтров не доходят — балансировщик передаёт их между парными портами.
## 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры
При блокировке ресурсов фильтру необходимо отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) или **TCP Reset** (для HTTPS-трафика). Особенность связана с тем, что канал между балансировщиком и фильтром фактически **однонаправленный** с точки зрения конкретного порта.
При блокировке ресурса фильтр отправляет абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) для HTTP или **TCP Reset** для HTTPS: подменить содержимое зашифрованного соединения невозможно, а сам ресурс определяется по SNI в ClientHello ([раздел 17.5.3](17.md)). Для трафика без MPLS-меток фильтр формирует такой пакет сам.
Если трафик содержит MPLS-метки или другую инкапсуляцию, фильтр не может самостоятельно сгенерировать ответный пакет с правильными заголовками. Поэтому используется следующая логика:
С MPLS-трафиком так не получается. MPLS-путь однонаправлен: метки, с которыми пакет абонента пришёл на фильтр, действительны только для направления в сторону интернета, а стек меток обратного направления фильтру неизвестен — собранный им самим пакет оборудование оператора отбросит или доставит не туда. Поэтому для трафика с MPLS-метками используется другая логика:
1. Пакет от абонента в сторону интернет-ресурса **пропускается** как есть;
2. Фильтр **ожидает обратный пакет** от интернет-ресурса в рамках той же сессии;
3. Когда обратный пакет приходит (уже с корректными MPLS-метками и заголовками), фильтр **подменяет** его содержимое на HTTP-редирект или TCP Reset;
4. Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции.
1. Пакет абонента к ресурсу **пропускается** как есть;
2. Фильтр **ожидает обратный пакет** от ресурса в рамках той же сессии;
3. Обратный пакет приходит уже с правильными метками обратного направления, и фильтр **подменяет** его содержимое на HTTP-редирект или TCP Reset, сохраняя метки;
4. Балансировщик по 4-байтному заголовку возвращает модифицированный пакет в тот же линк, и пакет доходит до абонента с корректной инкапсуляцией.
Для **HTTP** — подставляется редирект на страницу-заглушку. Для **HTTPS** — отправляется TCP Reset (так как содержимое зашифровано и подмена невозможна). В обоих случаях механизм одинаков: дождаться ответа сервера и подменить пакет.
Роль балансировщика здесь двоякая. Разбирая стек меток и вычисляя симметричный хэш по IP-адресам под ними, он приводит ответ сервера на тот же фильтр и то же ядро, которые обработали запрос абонента, хотя метки у ответа другие. А при возврате он не трогает метки и отправляет пакет строго в исходный линк, поэтому подменённый ответ проходит ровно тем же путём, что и настоящий ответ сервера. Решение о блокировке и отправке редиректа или Reset принимает фильтр ([раздел 5.1.5](05.md)).
---
chapters/05.md
+1 -1
View File
@@ -144,7 +144,7 @@
- Для **HTTP**-трафика абоненту отправляется **HTTP-редирект** (код 302) на страницу-заглушку оператора, информирующую о блокировке ресурса. URL страницы-заглушки задаётся параметром **redirect URL** в настройках DPI-листа.
- Для **HTTPS**-трафика содержимое зашифровано, поэтому подмена ответа невозможна. Вместо этого абоненту и серверу отправляется **TCP Reset**, разрывающий соединение.
- При наличии MPLS-меток или сложной инкапсуляции фильтр не может самостоятельно сгенерировать ответный пакет с корректными заголовками. Поэтому используется особая логика: пакет от абонента пропускается к серверу, фильтр **дожидается ответного пакета** в той же сессии, а затем **подменяет** его содержимое на редирект или TCP Reset, сохраняя оригинальные заголовки инкапсуляции (подробнее — в [разделе 4.8](04.md)).
- Для трафика с MPLS-метками фильтр не может самостоятельно сгенерировать ответный пакет: MPLS-путь однонаправлен, и стек меток обратного направления фильтру неизвестен. Поэтому используется особая логика: пакет от абонента пропускается к серверу, фильтр **дожидается ответного пакета** в той же сессии, а затем **подменяет** его содержимое на редирект или TCP Reset, сохраняя метки (подробнее — в [разделе 4.8](04.md)).
**Режим ignore** — используется для **распознавания протоколов** без блокировки. Фильтр определяет тип трафика и отправляет логи на SPFS, но сам трафик пропускает. Это первая стадия двухступенчатой блокировки: на этом этапе собираются данные для ЦСУ, которая формирует очищенные от ложных срабатываний списки и загружает их в другой DPI-лист, уже работающий в режиме block (подробнее — в [разделе 8](08.md)).
chapters/06.md
+1 -1
View File
@@ -70,7 +70,7 @@
- Для идентификации абонента необходимо **взаимодействовать с оператором** — запрашивать у него информацию о том, в какие порты и IP-адреса был транслирован конкретный абонент на CGNAT;
- Процесс диагностики становится **значительно более длительным** и требует координации между командой ТСПУ и оператором связи.
С точки зрения самой фильтрации (блокировки, распознавания протоколов) размещение после CGNAT не вносит каких-либо ограничений — функциональность ТСПУ остаётся полной. Неудобство касается исключительно диагностики и траблшутинга.
С точки зрения самой фильтрации (блокировки, распознавания протоколов) размещение после CGNAT не вносит каких-либо ограничений — функциональность ТСПУ остаётся полной. Основное неудобство касается диагностики и траблшутинга. Кроме того, за одним адресом NAT-пула стоит много абонентов, а балансировщик распределяет трафик по парам адресов, поэтому трафик многих абонентов к одному ресурсу попадает на одно ядро фильтра ([раздел 4.5.1](04.md)).
> **Примечание:** в ряде случаев подсистемы BRAS и CGNAT могут быть **совмещены в одном устройстве**. В этом случае участок «между BRAS и CGNAT» (наиболее удобная точка установки) попросту отсутствует — ТСПУ может быть установлено либо до этого комбинированного устройства, либо после него.
chapters/11.md
+10 -8
View File
@@ -93,20 +93,22 @@
│ │
│ Интерфейсы для трафика: │
│ │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ... │
│ │ 0 │ │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 │ │
│ │LAN │ │WAN │ │LAN │ │WAN │ │LAN │ │WAN │ │
│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │
│ чёт. нечёт. чёт. нечёт. чёт. нечёт. │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ... │
│ │te1 │ │te2 │ │te3 │ │te4 │ │te5 │ │te6 │ │
│ │WAN │ │LAN │ │WAN │ │LAN │ │WAN │ │LAN │ │
│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │
│ нечёт. чёт. нечёт. чёт. нечёт. чёт. │
└──────────────────────────────────────────────────┘
```
| Тип порта | Нумерация | Направление |
| --------- | ------------- | --------------------------------- |
| **LAN** | Чётные (0, 2, 4, 6...) | В сторону абонентов (от балансировщика) |
| **WAN** | Нечётные (1, 3, 5, 7...) | В сторону интернета (к балансировщику) |
| **LAN** | Чётные (te2, te4, te6…) | В сторону абонентов; подключается к LAN-порту filter group балансировщика |
| **WAN** | Нечётные (te1, te3, te5…) | В сторону интернета; подключается к WAN-порту filter group балансировщика |
Этот принцип чётных/нечётных портов **един** для всех моделей и поколений фильтров. Он же используется на балансировщиках EcoFilter Balancer (но **не соблюдается** на Eco Highway — подробнее в [разделе 7.4.1](07.md)).
Интерфейсы нумеруются с единицы и объединены в пары соседних номеров (te1/te2, te3/te4 …): в каждой паре чётный — LAN, нечётный — WAN.
Этот принцип чётных/нечётных портов **един** для всех моделей и поколений фильтров. Тот же принцип по договорённости принят при проектировании на балансировщиках EcoFilter Balancer, где жёсткой привязки нет ([раздел 4.3.1](04.md)); на Eco Highway он **не соблюдается** ([раздел 7.4.1](07.md)).
Разделение LAN/WAN прослеживается через всё оборудование ТСПУ — от байпасов через балансировщики до фильтров. Это фундаментальный принцип архитектуры: трафик от абонентов всегда приходит со стороны LAN, трафик из интернета — со стороны WAN.
chapters/20.md
+1 -1
View File
@@ -35,7 +35,7 @@
В проекте ТСПУ типовые скорости — **10G** и **100G**.
Каждый физический порт QSFP28 разделён на **четыре линии** (lane 0–3), каждая из которых может работать на скорости до 25 Гбит/с. Объединение всех четырёх линий даёт суммарную скорость 100 Гбит/с.
Каждый физический порт QSFP28 разделён на **четыре линии** (lane 1–4), каждая из которых может работать на скорости до 25 Гбит/с. Объединение всех четырёх линий даёт суммарную скорость 100 Гбит/с.
> **Примечание:** management-интерфейс работает **только** на скорости 1 Гбит/с Ethernet. Скорости 10 и 100 Мбит/с не поддерживаются.
chapters/21.md
+64 -62
View File
@@ -121,9 +121,9 @@ CLI балансировщика, как и у фильтра, имеет **дв
| Параметр | Описание |
| --------------- | ------------------------------------------------------------ |
| **Имя порта** | Произвольное имя (рекомендуется формат `P<порт><линия>`) |
| **Имя порта** | Произвольное имя (рекомендуется формат `p<порт>-<линия>`, для 100G — `p<порт>`) |
| **number** | Номер физического интерфейса на лицевой панели (1–32) |
| **lane** | Номер линии внутри физического порта (0–3) |
| **lane** | Номер линии внутри физического порта (1–4) |
| **speed** | Скорость порта: 10G, 25G или 100G |
| **mtu** | Максимальный размер кадра |
| **description** | Текстовое описание порта |
@@ -131,8 +131,8 @@ CLI балансировщика, как и у фильтра, имеет **дв
Пример конфигурации двух 10-гигабитных портов на одном физическом интерфейсе:
```text
set ports P21 number 2 lane 1 speed 10g
set ports P22 number 2 lane 2 speed 10g
set ports p2-1 number 2 lane 1 speed 10g
set ports p2-2 number 2 lane 2 speed 10g
```
### 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed)
@@ -140,30 +140,30 @@ CLI балансировщика, как и у фильтра, имеет **дв
Имя порта может быть **произвольным**, однако рекомендуется придерживаться единообразной схемы именования, отражающей номер физического порта и номер линии:
```text
P<номер_порта><номер_линии>
p<номер_порта>-<номер_линии>
```
Например:
| Имя порта | Физический порт | Линия | Скорость | Описание |
| --------- | --------------- | ----- | -------- | ------------------------------------ |
| `P21` | 2 | 1 | 10G | Порт 2, линия 1 — первый 10G-канал |
| `P22` | 2 | 2 | 10G | Порт 2, линия 2 — второй 10G-канал |
| `P2` | 2 | — | 100G | Порт 2, все линии — 100G-канал |
| `p2-1` | 2 | 1 | 10G | Порт 2, линия 1 — первый 10G-канал |
| `p2-2` | 2 | 2 | 10G | Порт 2, линия 2 — второй 10G-канал |
| `p2` | 2 | — | 100G | Порт 2, все линии — 100G-канал |
### 21.3.2. 10G: указание lane (0–3), 100G: все lane задействованы
### 21.3.2. 10G: указание lane (1–4), 100G: все lane задействованы
Поведение параметра **lane** зависит от выбранной скорости:
**При 10G (или 25G):**
Каждый физический порт QSFP28 содержит 4 линии. При использовании гидры (breakout-кабеля) каждая линия становится отдельным 10-гигабитным портом. Для каждого такого порта необходимо явно указать номер линии (`lane 0`, `lane 1`, `lane 2`, `lane 3`):
Каждый физический порт QSFP28 содержит 4 линии. При использовании гидры (breakout-кабеля) каждая линия становится отдельным 10-гигабитным портом. Для каждого такого порта необходимо явно указать номер линии (`lane 1`, `lane 2`, `lane 3`, `lane 4`):
```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
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 Гбит/с.
@@ -173,7 +173,7 @@ CLI балансировщика, как и у фильтра, имеет **дв
Все 4 линии объединены в один канал. Параметр `lane` **не указывается**, так как задействованы все линии:
```text
set ports P2 number 2 speed 100g
set ports p2 number 2 speed 100g
```
> **Рекомендация:** все физические порты настраиваются в соответствии со схемой организации связи на конкретной площадке. Единых «стандартных» настроек нет — конфигурация полностью зависит от того, какие устройства и на каких скоростях подключены к балансировщику.
@@ -208,7 +208,7 @@ CLI балансировщика, как и у фильтра, имеет **дв
Пример:
```text
set links link1 lan-port P21 wan-port P22
set links link1 lan-port p2-2 wan-port p2-1
set links link1 description "Bypass1-Mon0/Mon1"
```
@@ -235,8 +235,8 @@ CLI балансировщика, как и у фильтра, имеет **дв
│ ... │ rules │ │ │ Group 3 │──► Фильтр 2
└─────────┘ └──────┬──────┘ │ ... │
│ └───────────┘
Профиль проверки
доступности
Профиль Keep-Alive
(liveness)
```
### 21.5.1. Привязка групп портов в сторону фильтров (filter groups)
@@ -256,17 +256,17 @@ CLI балансировщика, как и у фильтра, имеет **дв
Каждая filter group объединяет один LAN-порт и один WAN-порт, смотрящие в сторону конкретной пары интерфейсов фильтра.
### 21.5.2. N_UNIT_QA: количество ядер фильтра минус один
### 21.5.2. nat-unit-queues: количество ядер фильтра минус один
Параметр **N_UNIT_QA** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика:
Параметр **`nat-unit-queues`** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика:
```text
set balance-group <имя_группы> n-unit-qa <число>
set ecofilter-balancer nat-unit-queues <число>
```
Значение **всегда равно общему количеству ядер процессора фильтра минус один**:
| Модель фильтра | Ядер всего | N_UNIT_QA |
| Модель фильтра | Ядер всего | nat-unit-queues |
| ----------------------------- | ---------- | --------- |
| Xeon 2695 (18 ядер) | 18 | 17 |
| Xeon 2699 (22 ядра) | 22 | 21 |
@@ -274,59 +274,59 @@ CLI балансировщика, как и у фильтра, имеет **дв
Причина вычитания единицы: на фильтре **все ядра, кроме одного**, отданы под процесс EcoNAT, который обрабатывает трафик. Одно ядро — **сервисное**: на нём работает Linux, системные логи, управление. Оно не участвует в обработке трафика.
Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку.
Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр `cores`).
## 21.6. Профиль проверки доступности (keep-alive)
## 21.6. Профиль Keep-Alive (liveness profile)
К группе балансировки привязывается **профиль проверки доступности** (availability profile), определяющий параметры отправки keep-alive пакетов через группы портов в сторону фильтров.
```text
set balance-group <имя_группы> availability-profile <имя_профиля>
```
К группе балансировки привязывается **профиль Keep-Alive** (liveness profile, параметр группы `liveness-profile`), определяющий параметры отправки keep-alive-пакетов через группы портов в сторону фильтров.
Профиль настраивается отдельно:
```text
set availability-profile <имя_профиля> <параметр> <значение>
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 <число>
```
### 21.6.1. Начальная задержка, интервал, порог потерь
### 21.6.1. Допустимая задержка, интервал, пороги потерь и восстановления
| Параметр | Описание |
| -------------------------- | -------------------------------------------------------------------- |
| **Начальная задержка** | Время ожидания перед началом отправки keep-alive после поднятия интерфейсов (например, 1000 мс). Необходимо, чтобы фильтр успел полностью инициализировать интерфейсы |
| **Интервал** | Периодичность отправки keep-alive пакетов (например, 100 мс) |
| **Порог потерь (down)** | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5 пакетов) |
| **Порог восстановления (up)** | Количество последовательно полученных ответов, после которых неактивная filter group считается снова **активной** |
| **`initial-delay`** | По руководству производителя — максимально допустимая задержка между keep-alive-пакетами, при превышении которой срабатывает счётчик потерь; по эксплуатационным описаниям — пауза перед началом отправки keep-alive после поднятия интерфейсов, чтобы фильтр успел их инициализировать (например, 1000 мс). Подробнее — [раздел 4.6.1](04.md) |
| **`interval`** | Периодичность отправки keep-alive-пакетов, мс (например, 100) |
| **`probes-down-count`** | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5) |
| **`probes-up-count`** | Количество последовательно полученных ответов, после которых неактивная filter group снова считается **активной** (например, 5) |
Механизм работы: балансировщик отправляет keep-alive пакет в LAN-порт filter group и ожидает получить его через парный WAN-порт. Время прохождения пакета (time of pass) измеряется в наносекундах и в нормальном состоянии составляет порядка **20–30 микросекунд**.
Механизм работы: балансировщик отправляет keep-alive пакет в LAN-порт filter group и ожидает получить его через парный WAN-порт. Время прохождения пакета (`time-on-path`) измеряется в наносекундах — например, около 27 мкс; конкретное значение зависит от площадки.
При потере заданного количества последовательных пакетов filter group переводится в состояние **bypass** — трафик не отправляется на фильтр, а перекладывается из одного порта в другой на уровне логики балансировщика.
### 21.6.2. Минимальное количество активных пар
Параметр **минимальное количество активных пар** (minimum active pairs) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной.
Параметр **минимальное количество активных пар** (`active-pairs`) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной.
Пример: если задано значение 8, то группа балансировки будет считаться рабочей, пока хотя бы 8 filter groups активны — неважно, сколько их всего.
> **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, и балансировщик включал bypass на всех линках. Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко.
> **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, балансировщик прекращал отправку heartbeat на байпас GL Sun, и тот переводил линки в аппаратный байпас с флапом у оператора ([раздел 3.3.1](03.md)). Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко.
### 21.6.3. Перебалансировка: включение/выключение
Параметр **перебалансировки** (rebalancing) определяет, что происходит при выходе из строя одной из filter groups:
Параметр **перебалансировки** (`rebalance`, значения enable/disable) задаётся в настройках группы балансировки, а не в профиле Keep-Alive, и определяет, что происходит при выходе из строя одной из filter groups:
| Значение | Поведение |
| --------------- | ---------------------------------------------------------------------- |
| **Включена** | Трафик пересчитывается и распределяется по оставшимся filter groups |
| **Выключена** | Для упавшей filter group включается программный bypass, остальные работают без изменений |
**Перебалансировка** занимает определённое время и вычислительные ресурсы. При пересчёте хэша сессии могут попасть на **другие интерфейсы и другие фильтры**, что в общем случае может быть нежелательным (разрыв DPI-сессий, потеря контекста анализа).
**Перебалансировка** занимает определённое время и вычислительные ресурсы. При пересчёте хэша сессии могут попасть на **другие интерфейсы и другие фильтры**, что в общем случае может быть нежелательным: новый фильтр видит такие сессии «с середины», а контекст анализа на прежнем фильтре теряется.
> **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или разрыв всех сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную.
> **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или массовый переезд сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную.
## 21.7. Настройка фильтров (Flow rules)
**Фильтры** (flow rules) на балансировщике — это правила, определяющие, что делать с трафиком, поступающим через линки. Каждое правило состоит из двух частей:
**Фильтр** на балансировщике — именованный набор правил (flows), который привязывается к линкам в сторону оператора (параметр `apply-to-links`, [раздел 21.7.4](#2174-привязка-фильтров-к-линкам)). Каждое правило состоит из условия (match) и действия (action); порядок проверки задаёт приоритет (priority, [раздел 21.7.3](#2173-приоритеты-правил)):
| Часть | Описание |
| ---------- | ----------------------------------------------------------- |
@@ -351,19 +351,19 @@ CLI балансировщика, как и у фильтра, имеет **дв
Match-условия можно использовать как для **включения** трафика в обработку, так и для **исключения** определённого трафика.
### 21.7.2. Actions: `balancing s_mac` → balance group / `bypass`
### 21.7.2. Actions: `balancing-as mag-hash` → balance group / `bypass`
Действие (action) определяет, что происходит с пакетом при совпадении:
| Action | Описание |
| ----------------------- | ---------------------------------------------------------------- |
| **balancing s_mac** | Отправить трафик на группу балансировки. Балансировка выполняется по хэшу от source IP, destination IP и протокола |
| **balancing-as mag-hash** | Отправить трафик на группу балансировки. Балансировка выполняется по хэшу от source IP, destination IP и протокола |
| **bypass** | Пропустить трафик прозрачно — переложить из одного порта в другой, не отправляя на фильтры |
При использовании `balancing s_mac` дополнительно указывается **целевая группа балансировки**:
При использовании `balancing-as mag-hash` дополнительно указывается **целевая группа балансировки**:
```text
set filters <имя_фильтра> flows <имя_правила> action balancing s_mac
set filters <имя_фильтра> flows <имя_правила> action balancing-as mag-hash
set filters <имя_фильтра> flows <имя_правила> to-balance-group <имя_группы>
```
@@ -371,7 +371,7 @@ Match-условия можно использовать как для **вкл
```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 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
```
@@ -392,9 +392,9 @@ Match-условия можно использовать как для **вкл
```text
Приоритет Правило Action
─────────────────────────────────────────────────────
100 VLAN 1 → на фильтр balancing s_mac
90 VLAN 2 → на фильтр balancing s_mac
80 VLAN 3 → на фильтр balancing s_mac
100 VLAN 1 → на фильтр balancing-as mag-hash
90 VLAN 2 → на фильтр balancing-as mag-hash
80 VLAN 3 → на фильтр balancing-as mag-hash
... ... ...
1 Всё остальное → bypass bypass
```
@@ -408,13 +408,13 @@ Match-условия можно использовать как для **вкл
После настройки правил необходимо **привязать фильтр к линкам** — указать, на каких линках (в сторону оператора) данные правила будут действовать:
```text
set filters <имя_фильтра> links [ <линк1> <линк2> ... ]
set filters <имя_фильтра> apply-to-links [ <линк1> <линк2> ... ]
```
Пример:
```text
set filters main links [ link1 link2 link3 link4 ]
set filters main apply-to-links [ link1 link2 link3 link4 ]
```
Один набор правил (фильтр) может быть привязан к **нескольким линкам** одновременно. Все линки, привязанные к фильтру, используют одни и те же flow rules.
@@ -427,13 +427,15 @@ Match-условия можно использовать как для **вкл
| Параметр | Описание |
| --------------------------- | --------------------------------------------------------------- |
| **IPv4-адрес байпаса** | IP-адрес байпаса GL Sun |
| **Порт** | Порт для heartbeat-протокола |
| **Период отсылки** | Интервал отправки heartbeat (в конфигурации задаётся в наносекундах; фактические единицы стоит проверить по документации балансировщика) |
| **Группа балансировки** | Группа, для которой работает отправка heartbeat |
| **Список линков байпаса** | Идентификаторы сущностей на стороне байпаса GL Sun |
| **ToS** | Тип сервиса в IP-заголовке heartbeat-пакетов |
| **Автоматический возврат** | Возможность автоматического возврата трафика в режим primary при восстановлении группы балансировки |
| **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`.
@@ -470,10 +472,10 @@ Management-интерфейс обеспечивает доступ к устр
│
5. Настроить группу балансировки (balance group)
└── Создать filter groups (пары портов в сторону фильтров)
└── Задать N_UNIT_QA
└── Привязать профиль проверки доступности
└── Задать nat-unit-queues
└── Привязать профиль Keep-Alive
│
6. Настроить профиль проверки доступности (availability profile)
6. Настроить профиль Keep-Alive (liveness profile)
│
7. Настроить фильтры (flow rules) — правила обработки трафика
└── Привязать фильтры к линкам
chapters/22.md
+17 -16
View File
@@ -158,35 +158,35 @@
В нормальном рабочем состоянии **все filter groups** должны находиться в состоянии `up`.
Переход в `bypass` происходит автоматически при потере заданного количества последовательных keep-alive пакетов (по умолчанию — 5). Обратный переход в `up` также автоматический — при получении достаточного количества ответных keep-alive пакетов.
Переход в `bypass` происходит автоматически при потере заданного количества последовательных keep-alive пакетов (параметр `probes-down-count`, в типовой конфигурации — 5). Обратный переход в `up` также автоматический — при получении достаточного количества ответных keep-alive пакетов.
### 22.6.2. Time of pass — время прохождения keep-alive пакета
### 22.6.2. time-on-path — время прохождения keep-alive пакета
Внутри каждой filter group отображается параметр **time of pass** — время прохождения keep-alive пакета через фильтр:
Внутри каждой filter group отображается параметр **`time-on-path`** — время прохождения keep-alive пакета через фильтр (отдельно для направлений to-lan и to-wan):
```text
Filter Group fg1:
Status: up
Time of pass: 27000 ns
time-on-path: 27000 ns
```
| Параметр | Описание |
| ------------------ | ----------------------------------------------------------------- |
| **Time of pass** | Время (в наносекундах) между отправкой keep-alive пакета в LAN-порт и получением его из парного WAN-порта |
| **Time of receipt**| Внутренний timestamp — привязан к внутреннему счётчику, практической ценности для эксплуатации не имеет |
| **time-on-path** | Время (в наносекундах) между отправкой keep-alive пакета в LAN-порт и получением его из парного WAN-порта |
| **time-of-receipt**| Внутренний timestamp — привязан к внутреннему счётчику, практической ценности для эксплуатации не имеет |
Механизм измерения:
1. Балансировщик отправляет keep-alive пакет в **LAN-порт** filter group;
2. Пакет проходит через фильтр (прозрачно, минуя DPI);
3. Балансировщик получает пакет из **WAN-порта** той же filter group;
4. Фиксируется разница во времени — это и есть **time of pass**.
4. Фиксируется разница во времени — это и есть **time-on-path**.
В нормальном состоянии time of pass составляет порядка **20–30 микросекунд** (20 000–30 000 наносекунд).
Например, time-on-path может составлять около 27 000 нс (27 мкс); конкретное значение зависит от площадки.
> **Важно:** балансировщик **ничего не знает** о работе DPI на фильтрах. Keep-alive пакеты проходят через фильтр прозрачно, без обработки движком DPI. Параметр time of pass отражает исключительно время прохождения пакета через аппаратную часть фильтра.
> **Важно:** балансировщик **ничего не знает** о работе DPI на фильтрах. Keep-alive-пакеты проходят через фильтр без обработки движком DPI. Параметр `time-on-path` отражает время прохождения пакета от балансировщика через фильтр и обратно, включая первую проверку («IP-пакет или нет»), которую выполняет процессор фильтра ([раздел 4.6.1](04.md)).
Если пакеты начинают теряться — time of pass резко возрастает. После потери **5 последовательных** keep-alive пакетов filter group переводится в состояние `bypass`.
Если пакеты начинают теряться — time-on-path резко возрастает. После потери **5 последовательных** keep-alive пакетов filter group переводится в состояние `bypass`.
### Влияние загрузки фильтра на keep-alive
@@ -201,16 +201,17 @@
## 22.7. Программный байпас: индивидуально для каждой группы портов
Программный bypass на балансировщике может управляться как **автоматически** (по результатам keep-alive), так и **вручную**:
Программный bypass на балансировщике может управляться как **автоматически** (по результатам keep-alive — для отдельных filter groups), так и **вручную** — для группы балансировки целиком:
```text
call balance-group <имя_группы> software-bypass <режим>
call ecofilter-balancer set-bypass-ecofilter-unit unit <имя_группы> {auto | bypass | primary}
```
| Режим | Описание |
| ------------ | ------------------------------------------------------------------- |
| **bypass** | Принудительно перевести группу в режим программного bypass |
| **primary** | Вернуть группу в нормальный режим работы (трафик на фильтры) |
| Режим | Описание |
| ------------ | ----------------------------------------------------------------------------------------- |
| **auto** | Штатный режим: трафик направляется на фильтры, пока группа балансировки активна; если она неактивна — включается bypass |
| **bypass** | Принудительный программный bypass: трафик группы пропускается прозрачно, мимо фильтров |
| **primary** | Трафик принудительно направляется на группу балансировки |
### Индивидуальный bypass для каждой filter group
chapters/24.md
+5 -3
View File
@@ -50,6 +50,8 @@
Первый практический шаг — **найти сессии** конкретного абонента к конкретному ресурсу на фильтрах площадки.
Балансировщик не ведёт журнала распределения и не сообщает, на какой фильтр отправлена сессия ([раздел 4.5.4](04.md)), поэтому поиск выполняется на каждом фильтре площадки — вручную или простым скриптом. Оба направления сессии всегда находятся на одном и том же фильтре.
### Поиск по локальному адресу
Для поиска сессий используется команда `show session` с фильтрацией по локальному адресу абонента:
@@ -83,7 +85,7 @@
| Результат | Интерпретация |
| -------------------------------------- | ---------------------------------------------------------- |
| Сессии **найдены** | Трафик абонента проходит через фильтр — ТСПУ его видит |
| Сессии **не найдены** | Трафик не проходит через данный фильтр — абонент идёт другим путём, либо проблема до ТСПУ |
| Сессии **не найдены ни на одном фильтре** | Трафик абонента не проходит через ТСПУ — абонент идёт другим путём, либо проблема до ТСПУ |
| Сессии есть, но ресурс недоступен | Возможна блокировка на уровне DPI — проверить DPI-листы |
> **Важно:** при поиске сессий помните принцип «локальный адрес всегда на первом месте» (см. [раздел 12](12.md)). Независимо от направления трафика, IP-адрес абонента записывается в поле local. Если в поле local отображаются адреса, которые не являются абонентскими (интернет-адреса), — это признак перепутки LAN/WAN (см. раздел 24.6).
@@ -124,13 +126,13 @@
Наиболее удобный способ — программный bypass на балансировщике (см. [раздел 22.7](22.md)):
```text
call balance-group <группа> software-bypass bypass
call ecofilter-balancer set-bypass-ecofilter-unit unit <группа> bypass
```
Преимущества:
- **Нет флапов линков** — оператор ничего не замечает;
- **Гранулярность** — можно байпасить отдельные filter groups;
- **Гранулярность** — отдельные filter groups байпасятся автоматически по keep-alive, вручную переключается группа балансировки целиком ([раздел 4.6.2](04.md));
- **Мгновенность** — переключение происходит немедленно.
### Bypass по правилам фильтрации (flow rules)