From aa7c3f3132f9b10a5efcd6906053410e6c226c99 Mon Sep 17 00:00:00 2001 From: Daniel Lavrushin Date: Wed, 23 Sep 2026 20:00:05 +0200 Subject: [PATCH] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D0=B8=D0=B5=20=D0=B4=D0=BE=D0=BA=D1=83=D0=BC=D0=B5=D0=BD?= =?UTF-8?q?=D1=82=D0=B0=D1=86=D0=B8=D0=B8:=20=D0=B2=D0=BD=D0=B5=D1=81?= =?UTF-8?q?=D0=B5=D0=BD=D1=8B=20=D0=B8=D0=B7=D0=BC=D0=B5=D0=BD=D0=B5=D0=BD?= =?UTF-8?q?=D0=B8=D1=8F=20=D0=B2=20=D0=B3=D0=BB=D0=B0=D0=B2=D1=8B=2005,=20?= =?UTF-8?q?06,=2011,=2020,=2021,=2022=20=D0=B8=2024.=20=D0=98=D1=81=D0=BF?= =?UTF-8?q?=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D1=8B=20=D1=84=D0=BE=D1=80?= =?UTF-8?q?=D0=BC=D1=83=D0=BB=D0=B8=D1=80=D0=BE=D0=B2=D0=BA=D0=B8,=20?= =?UTF-8?q?=D1=83=D1=82=D0=BE=D1=87=D0=BD=D0=B5=D0=BD=D1=8B=20=D1=82=D0=B5?= =?UTF-8?q?=D1=85=D0=BD=D0=B8=D1=87=D0=B5=D1=81=D0=BA=D0=B8=D0=B5=20=D0=B4?= =?UTF-8?q?=D0=B5=D1=82=D0=B0=D0=BB=D0=B8,=20=D0=B8=D0=B7=D0=BC=D0=B5?= =?UTF-8?q?=D0=BD=D0=B5=D0=BD=D1=8B=20=D0=BF=D0=B0=D1=80=D0=B0=D0=BC=D0=B5?= =?UTF-8?q?=D1=82=D1=80=D1=8B=20=D0=B8=20=D0=BE=D0=BF=D0=B8=D1=81=D0=B0?= =?UTF-8?q?=D0=BD=D0=B8=D1=8F=20=D0=B4=D0=BB=D1=8F=20=D1=83=D0=BB=D1=83?= =?UTF-8?q?=D1=87=D1=88=D0=B5=D0=BD=D0=B8=D1=8F=20=D0=BF=D0=BE=D0=BD=D0=B8?= =?UTF-8?q?=D0=BC=D0=B0=D0=BD=D0=B8=D1=8F=20=D1=80=D0=B0=D0=B1=D0=BE=D1=82?= =?UTF-8?q?=D1=8B=20=D1=81=D0=B8=D1=81=D1=82=D0=B5=D0=BC=D1=8B.=20=D0=92?= =?UTF-8?q?=20=D1=87=D0=B0=D1=81=D1=82=D0=BD=D0=BE=D1=81=D1=82=D0=B8,=20?= =?UTF-8?q?=D0=BE=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB=D0=B5=D0=BD=D1=8B=20=D0=BE?= =?UTF-8?q?=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=B8=D1=8F=20=D0=B4=D0=BB=D1=8F?= =?UTF-8?q?=20MPLS-=D1=82=D1=80=D0=B0=D1=84=D0=B8=D0=BA=D0=B0,=20=D0=B8?= =?UTF-8?q?=D0=BD=D1=82=D0=B5=D1=80=D1=84=D0=B5=D0=B9=D1=81=D0=BE=D0=B2,?= =?UTF-8?q?=20=D0=BF=D0=B0=D1=80=D0=B0=D0=BC=D0=B5=D1=82=D1=80=D0=BE=D0=B2?= =?UTF-8?q?=20=D0=BD=D0=B0=D1=81=D1=82=D1=80=D0=BE=D0=B9=D0=BA=D0=B8=20?= =?UTF-8?q?=D1=84=D0=B8=D0=BB=D1=8C=D1=82=D1=80=D0=BE=D0=B2=20=D0=B8=20?= =?UTF-8?q?=D0=BF=D1=80=D0=BE=D1=84=D0=B8=D0=BB=D0=B5=D0=B9=20Keep-Alive.?= =?UTF-8?q?=20=D0=A2=D0=B0=D0=BA=D0=B6=D0=B5=20=D0=B4=D0=BE=D0=B1=D0=B0?= =?UTF-8?q?=D0=B2=D0=BB=D0=B5=D0=BD=D1=8B=20=D0=BF=D0=BE=D1=8F=D1=81=D0=BD?= =?UTF-8?q?=D0=B5=D0=BD=D0=B8=D1=8F=20=D0=BF=D0=BE=20=D1=80=D0=B0=D0=B1?= =?UTF-8?q?=D0=BE=D1=82=D0=B5=20=D1=81=20=D1=81=D0=B5=D1=81=D1=81=D0=B8?= =?UTF-8?q?=D1=8F=D0=BC=D0=B8=20=D0=B8=20=D0=BF=D1=80=D0=BE=D0=B3=D1=80?= =?UTF-8?q?=D0=B0=D0=BC=D0=BC=D0=BD=D1=8B=D0=BC=20=D0=B1=D0=B0=D0=B9=D0=BF?= =?UTF-8?q?=D0=B0=D1=81=D0=BE=D0=BC.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 13 ++- chapters/02.md | 8 +- chapters/03.md | 2 +- chapters/04.md | 296 ++++++++++++++++++++++++++++--------------------- chapters/05.md | 2 +- chapters/06.md | 2 +- chapters/11.md | 18 +-- chapters/20.md | 2 +- chapters/21.md | 126 ++++++++++----------- chapters/22.md | 33 +++--- chapters/24.md | 8 +- 11 files changed, 283 insertions(+), 227 deletions(-) diff --git a/README.md b/README.md index 7cf5530..d736f36 100644 --- a/README.md +++ b/README.md @@ -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) diff --git a/chapters/02.md b/chapters/02.md index 222aa4c..67d70de 100644 --- a/chapters/02.md +++ b/chapters/02.md @@ -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: Обработка на фильтре diff --git a/chapters/03.md b/chapters/03.md index b4e9b7a..66902e4 100644 --- a/chapters/03.md +++ b/chapters/03.md @@ -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-пакеты байпаса **не доходят до фильтров** — они заворачиваются обратно на уровне балансировщика. Таким образом, существуют **две независимые стадии** проверки отказоустойчивости: diff --git a/chapters/04.md b/chapters/04.md index 02c0526..c6f1baa 100644 --- a/chapters/04.md +++ b/chapters/04.md @@ -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)). --- diff --git a/chapters/05.md b/chapters/05.md index c30de72..cc1b6eb 100644 --- a/chapters/05.md +++ b/chapters/05.md @@ -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)). diff --git a/chapters/06.md b/chapters/06.md index 16e3579..6809fbb 100644 --- a/chapters/06.md +++ b/chapters/06.md @@ -70,7 +70,7 @@ - Для идентификации абонента необходимо **взаимодействовать с оператором** — запрашивать у него информацию о том, в какие порты и IP-адреса был транслирован конкретный абонент на CGNAT; - Процесс диагностики становится **значительно более длительным** и требует координации между командой ТСПУ и оператором связи. -С точки зрения самой фильтрации (блокировки, распознавания протоколов) размещение после CGNAT не вносит каких-либо ограничений — функциональность ТСПУ остаётся полной. Неудобство касается исключительно диагностики и траблшутинга. +С точки зрения самой фильтрации (блокировки, распознавания протоколов) размещение после CGNAT не вносит каких-либо ограничений — функциональность ТСПУ остаётся полной. Основное неудобство касается диагностики и траблшутинга. Кроме того, за одним адресом NAT-пула стоит много абонентов, а балансировщик распределяет трафик по парам адресов, поэтому трафик многих абонентов к одному ресурсу попадает на одно ядро фильтра ([раздел 4.5.1](04.md)). > **Примечание:** в ряде случаев подсистемы BRAS и CGNAT могут быть **совмещены в одном устройстве**. В этом случае участок «между BRAS и CGNAT» (наиболее удобная точка установки) попросту отсутствует — ТСПУ может быть установлено либо до этого комбинированного устройства, либо после него. diff --git a/chapters/11.md b/chapters/11.md index 6df9411..addc36e 100644 --- a/chapters/11.md +++ b/chapters/11.md @@ -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. diff --git a/chapters/20.md b/chapters/20.md index 6f67834..9b7cc93 100644 --- a/chapters/20.md +++ b/chapters/20.md @@ -35,7 +35,7 @@ В проекте ТСПУ типовые скорости — **10G** и **100G**. -Каждый физический порт QSFP28 разделён на **четыре линии** (lane 0–3), каждая из которых может работать на скорости до 25 Гбит/с. Объединение всех четырёх линий даёт суммарную скорость 100 Гбит/с. +Каждый физический порт QSFP28 разделён на **четыре линии** (lane 1–4), каждая из которых может работать на скорости до 25 Гбит/с. Объединение всех четырёх линий даёт суммарную скорость 100 Гбит/с. > **Примечание:** management-интерфейс работает **только** на скорости 1 Гбит/с Ethernet. Скорости 10 и 100 Мбит/с не поддерживаются. diff --git a/chapters/21.md b/chapters/21.md index 4a63f9d..3083a56 100644 --- a/chapters/21.md +++ b/chapters/21.md @@ -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) — правила обработки трафика └── Привязать фильтры к линкам diff --git a/chapters/22.md b/chapters/22.md index 6249375..19c360b 100644 --- a/chapters/22.md +++ b/chapters/22.md @@ -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 diff --git a/chapters/24.md b/chapters/24.md index 36441d6..4a11d56 100644 --- a/chapters/24.md +++ b/chapters/24.md @@ -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)