# 7. Эшелонированная система (ТСПУ тип Б) [← Оглавление](../README.md) · [← Раздел 6: Места установки ТСПУ](06.md) --- ## 7.1. Назначение: обработка трафика, не прошедшего через ТСПУ тип А Эшелонированная система (ТСПУ тип Б, второй эшелон) предназначена для **обработки трафика, который не прошёл через стандартные ТСПУ** (тип А, первый эшелон). Когда в тексте упоминается просто «ТСПУ» без уточнения типа, подразумевается **ТСПУ тип А** — именно этот тип рассматривался во всех предыдущих разделах. ТСПУ тип А устанавливается у большинства операторов и покрывает основную массу трафика. Однако у крупных операторов связи существуют ситуации, когда часть трафика не может быть обработана стандартными средствами — для таких случаев создана эшелонированная система. image Идея эшелонирования возникла как способ **сократить общее количество ТСПУ**, развёртываемых по стране. Вместо установки ТСПУ тип А у каждого мелкого оператора на уровне доступа, можно у нескольких крупных операторов в ключевых точках установить двухстадийную систему фильтрации, что позволяет снизить затраты на реализацию проекта. ## 7.2. Проблема асимметричного трафика у крупных операторов Сеть крупного оператора связи, если идти от абонентов к выходу в интернет, делится на несколько сегментов: ```text ┌─────────────────────────────────────────────────────────┐ │ Сегмент доступа и распределения │ │ • Абоненты │ │ • Небольшие операторы (single-home) │ │ • Корпоративные заказчики с одним подключением │ │ │ │ → Обрабатывается ТСПУ тип А (без проблем) │ └────────────────────────┬────────────────────────────────┘ │ ┌────────────────────────┴────────────────────────────────┐ │ Уровень ядра и пиринга │ │ • Крупные операторы связи │ │ • Крупные корпоративные заказчики │ │ • Несколько выходов в интернет │ │ │ │ → Возможен асимметричный трафик │ │ → Требуется ТСПУ тип Б (эшелон) │ └─────────────────────────────────────────────────────────┘ ``` На уровне доступа и распределения подключены абоненты и небольшие операторы с единственным каналом связи (single-home). У них нет собственной автономной системы и собственной IP-адресации — адреса выделяет крупный оператор. Весь их трафик проходит через одну точку и обрабатывается стандартным **ТСПУ тип А** без каких-либо проблем. На уровне ядра и пиринга подключаются **крупные операторы** и заказчики, которые могут иметь **несколько выходов в интернет** — через разных провайдеров. Их трафик может: - выходить через одного оператора, а **возвращаться через другого**; - проходить через ТСПУ только в одном направлении. В таких случаях традиционная схема фильтрации **не работает**: на фильтре ТСПУ тип А сессия «не соберётся», потому что одна сторона сессии проходит через ТСПУ, а ответная — возвращается иным путём, минуя его. Для обработки такого **асимметричного трафика** и предназначен ТСПУ тип Б. ## 7.3. Балансировщик Eco Highway Эшелонированная система, как и ТСПУ тип А, состоит из балансировщика и фильтров, но с существенными отличиями. Балансировщик эшелона называется **Eco Highway** (в отличие от **EcoFilter Balancer** в ТСПУ тип А). Аппаратная платформа **одинакова** — это тот же одноюнитовый 32-портовый коммутатор на базе чипа **Barefoot Tofino**. Различается только **программное обеспечение**. Ключевое отличие Eco Highway: он **сам выполняет фильтрацию трафика** на основе заголовков L3/L4 (IP-адреса, порты), а не просто распределяет трафик по фильтрам. ### 7.3.1. BGP-загрузка списков фильтрации из ЦСУ В отличие от EcoFilter Balancer, где правила фильтрации (flow rules) задаются вручную и исчисляются единицами, на Eco Highway списки фильтрации: - загружаются автоматически по протоколу **BGP** из центральной системы управления; - содержат **десятки и сотни тысяч правил**; - **не могут быть заданы вручную** — это не предусмотрено конструкцией. Списки организованы в виде нескольких таблиц, каждая из которых фильтрует по-своему: | Тип таблицы | Критерий фильтрации | | --------------------- | ----------------------------------------- | | IPv4 адрес + порт | IP-адрес, маска и порт TCP/UDP | | IPv4 адрес | Только IP-адрес (без порта) | | IPv6 | Аналогичные таблицы для IPv6-трафика | | Белый список | Ресурсы, исключённые из фильтрации | | Port redirect | Трафик, подлежащий отправке на фильтры | ### 7.3.2. Блокировка по IP-адресам на уровне балансировщика (Telegram, реестр РКН) Eco Highway самостоятельно блокирует трафик, который можно идентифицировать по IP-адресам и портам — **без отправки на фильтры**: - **Реестр Роскомнадзора** (в части IP-адресов) — все правила блокировки по IP загружаются на балансировщик, что снижает нагрузку на фильтры; - **Блокировка протоколов** (например, Telegram) — очищенные списки IP-адресов и портов загружаются из ЦСУ по BGP. Принципиальное отличие от ТСПУ тип А: на первом эшелоне блокировка протоколов (Telegram и др.) выполняется **на фильтрах** с помощью DPI. На втором эшелоне эта блокировка выполняется **на самом балансировщике** по IP-спискам. Более того, в прошивке фильтров, предназначенных для эшелонированной системы, возможности блокировки протоколов (например, Telegram) **отсутствуют** — они просто не нужны, поскольку этим занимается Eco Highway. ### 7.3.3. Фильтры в режиме On-a-stick, VLAN-разделение LAN/WAN Фильтры в эшелонированной системе подключены **иначе**, чем в ТСПУ тип А: | Параметр | ТСПУ тип А (EcoFilter Balancer) | ТСПУ тип Б (Eco Highway) | | ------------------- | ------------------------------- | -------------------------------------- | | **Подключение** | Пары портов LAN + WAN | Режим on-a-stick (все порты равноправны) | | **Разделение LAN/WAN** | На уровне физических портов | На уровне VLAN-тегов | | **Чётность портов** | Чётные = LAN, нечётные = WAN | Не соблюдается | В режиме on-a-stick каждый физический порт фильтра **равноправен**. Разделение между LAN и WAN происходит на уровне специального VLAN-заголовка: 1. Eco Highway при отправке пакета на фильтр добавляет **VLAN-тег**, обозначающий направление (LAN); 2. Фильтр после обработки **меняет** этот VLAN-тег на другой (WAN); 3. Eco Highway по VLAN-тегу определяет направление и отправляет пакет дальше. Таким образом, логическое разделение LAN/WAN сохраняется, но на уровне физики все интерфейсы фильтра однотипные. ### 7.3.4. Фильтры занимаются только URL-фильтрацией по реестру РКН Поскольку блокировка по IP-адресам и протоколам выполняется самим Eco Highway, фильтры в эшелонированной системе занимаются **исключительно URL-фильтрацией** по реестру Роскомнадзора — той частью блокировки, которая требует глубокого анализа содержимого пакетов (DPI) и не может быть выполнена на уровне балансировщика. Это означает, что на фильтры отправляется **минимально возможный** объём трафика — только тот, который требует проверки по URL. Всё остальное обрабатывается или пропускается балансировщиком. Благодаря упрощённому функционалу (нет распознавания протоколов, нет логирования соединений) производительность фильтров на эшелоне **несколько выше**, чем на ТСПУ тип А — примерно на 15%. Однако разница невелика, и при проектировании рекомендуется использовать те же расчётные цифры производительности, что и для ТСПУ тип А. ## 7.4. Два конвейера (Pipeline) в Eco Highway Внутри чипа Barefoot Tofino, на котором построен балансировщик, существуют **два независимых конвейера** (Pipeline 1 и Pipeline 2) — логические структуры, обрабатывающие входящий трафик на высокой скорости. Каждый конвейер обладает собственным **независимым набором ресурсов**: памятью и вычислительной мощностью. На обычном балансировщике (EcoFilter Balancer) оба конвейера **настроены идентично** — в какой бы конвейер ни попал пакет, обработка будет одинаковой. На Eco Highway конвейеры **настраиваются по-разному** — это позволяет в два раза увеличить доступное количество правил фильтрации. ### 7.4.1. Разделение портов между конвейерами Все физические порты балансировщика **жёстко привязаны** к одному из двух конвейеров на заводском уровне — примерно половина портов обслуживается Pipeline 1, половина — Pipeline 2. На Eco Highway это разделение используется целенаправленно: - **LAN-порты** (в сторону оператора связи) прикрепляются к **одному конвейеру**; - **WAN-порты** (в сторону интернета) прикрепляются к **другому конвейеру**. Принцип чётных/нечётных портов, используемый на EcoFilter Balancer, на эшелоне **не соблюдается** и не имеет значения. ### 7.4.2. Физическая перемычка между конвейерами Поскольку конвейеры **логически изолированы** друг от друга внутри чипа (прямой связи между ними нет), для передачи пакета из одного конвейера в другой используется **физическая перемычка** (jumper) — кабель, соединяющий порт одного конвейера с портом другого. ```text ┌──────────────────────────────────────────────────┐ │ Eco Highway │ │ │ │ Pipeline 1 Pipeline 2 │ │ ┌────────────┐ ┌────────────┐ │ │ │ Таблицы │ │ Таблицы │ │ │ │ фильтрации │ │ фильтрации │ │ │ │ (набор A) │ │ (набор B) │ │ │ └──────┬─────┘ └──────┬─────┘ │ │ │ │ │ │ P41 ←┼── LAN-порты WAN-порты ──┼→ P91 │ │ P42 ←┘ ┌─┼→ P92 │ │ │ ┌──────────────┐ │ │ │ └─────┤ Перемычка ├─────────┘ │ │ └──────────────┘ │ │ │ │ │ │ Порты к фильтрам Порты к фильтрам │ └──────────────────────────────────────────────────┘ ``` Перемычка должна быть рассчитана на **весь объём трафика**, проходящего через балансировщик. В худшем случае весь трафик может пройти через перемычку, поэтому она не должна стать узким местом. При большом количестве высокоскоростных каналов может потребоваться несколько перемычек. ### 7.4.3. Прохождение пакета: drop / отправка на фильтр / переход на второй конвейер Когда пакет попадает на вход Eco Highway, он проходит следующий путь: **Шаг 1: Pipeline 1.** Пакет, вошедший через LAN-порт, попадает в конвейер, к которому этот порт привязан. Пакет проходит через все таблицы фильтрации данного конвейера. По результатам возможны **три исхода**: 1. **Drop** — пакет совпал с запрещающим правилом (например, IP-адрес Telegram) и **дропается**. Дальнейшая обработка не происходит; 2. **Отправка на фильтр** — пакет совпал с правилом перенаправления на фильтры (port redirect). Пакет отправляется на фильтр для URL-фильтрации, обрабатывается и **возвращается напрямую** оператору, минуя второй конвейер; 3. **Переход на Pipeline 2** — пакет не совпал ни с одним правилом первого конвейера. Пакет выходит через порт, принадлежащий Pipeline 1, проходит через **физическую перемычку** и попадает на вход Pipeline 2. **Шаг 2: Pipeline 2.** На втором конвейере пакет проходит через **другой набор правил** (отличающийся от первого). Результат аналогичен — drop, отправка на фильтр или пропуск дальше к оператору. Важно: после отправки на фильтр пакет **не проходит** через второй конвейер повторно. Обработанный фильтром пакет сразу отправляется оператору через нужный порт. Это было исправлено после первоначальной реализации, где пакет мог дважды попасть на фильтры. Также важно: хотя порты привязаны к конвейерам на входе, на **выходе** пакет может быть отправлен через **любой порт** — это логическая сущность обработки, а не жёсткая привязка входа к выходу. Пакет, пришедший через определённый LAN-порт, всё равно вернётся через **парный** ему WAN-порт (сохраняется привязка к линку оператора), но маршрут внутри балансировщика может быть произвольным. ### 7.4.4. Удвоение количества правил фильтрации Разделение правил между двумя конвейерами позволяет **в два раза увеличить** общее количество правил фильтрации на Eco Highway. Память внутри чипа Barefoot Tofino, хранящая эти правила, является **очень быстрой** (работает на скорости провода), но крайне ограниченной по объёму — это, по сути, программируемый TCAM (Content-Addressable Memory). Каждое дополнительное правило — на вес золота. На обычном EcoFilter Balancer, где оба конвейера идентичны, удвоение невозможно — один и тот же набор правил дублируется. На Eco Highway каждый конвейер несёт **свой уникальный набор**, удваивая суммарную ёмкость. ## 7.5. Отличия EcoFilter Balancer от Eco Highway | Характеристика | EcoFilter Balancer (тип А) | Eco Highway (тип Б) | | --------------------------- | -------------------------- | ------------------------------------------- | | **Аппаратная платформа** | Одинаковая | Одинаковая | | **Программное обеспечение** | Одно | Другое | | **Назначение** | Балансировка трафика | Балансировка + самостоятельная фильтрация | | **Правила фильтрации** | Вручную, единицы | По BGP из ЦСУ, десятки/сотни тысяч | | **Собственная фильтрация** | Нет (только bypass/balance)| Да (drop по L3/L4-заголовкам) | | **Конвейеры (Pipeline)** | Настроены идентично | Настроены по-разному (удвоение правил) | | **Перемычка** | Не требуется | Обязательна (физический кабель) | | **Подключение фильтров** | Пары LAN/WAN | On-a-stick (VLAN-разделение) | | **Связь с ЦСУ** | Только management | BGP для загрузки списков | | **Логирование** | Через фильтры | Отсутствует (только real-time) | Разрабатываются обе платформы **одной группой программистов**, и код во многом пересекается. Решения, созданные в рамках реализации Eco Highway, нередко переносятся на EcoFilter Balancer (например, команды программного байпаса), и наоборот. ## 7.6. Отсутствие логирования на Eco Highway (только real-time) На Eco Highway **не ведётся логирование** — информация о дропнутых и перенаправленных пакетах **не отправляется** на серверы логирования. Доступен только **просмотр в реальном времени** (real-time) на самом устройстве, без сохранения истории. Причина: объём трафика, проходящего через эшелон, **значительно больше**, чем через ТСПУ тип А. Если ТСПУ тип А обрабатывает трафик конкретного набора абонентов, то ТСПУ тип Б может пропускать через себя трафик множества операторов на уровне ядра сети. Логирование такого объёма потребовало бы несоразмерных ресурсов. Протокольные логи (для формирования очищенных списков блокировки) по-прежнему отправляются **только с фильтров первого эшелона** (ТСПУ тип А) через SPFS. Для диагностики на Eco Highway доступны следующие возможности: - **Просмотр списков в ЦСУ** — можно проверить, содержит ли конкретный IP-адрес или порт в загруженных списках; - **Программный байпас** — можно перевести Eco Highway в режим полного программного байпаса и проверить, восстанавливается ли доступность у оператора; - **Проверка на фильтрах** — убедиться, что нужная сессия не обрабатывается и на фильтрах второго эшелона. ## 7.7. Прозрачный пропуск трафика, уже обработанного ТСПУ тип А Eco Highway должен уметь **различать** трафик, уже обработанный ТСПУ тип А на первом эшелоне, и трафик, который первый эшелон не видел. Трафик, который **уже прошёл** через ТСПУ тип А (на нижнем уровне, на уровне доступа), **не должен обрабатываться повторно** на втором эшелоне. Для этого на Eco Highway предусмотрена возможность **прозрачного пропуска** такого трафика — он просто «пролетает насквозь» без фильтрации. Это позволяет избежать двойной обработки и связанных с ней проблем (удвоение сессий, ложные срабатывания, избыточная нагрузка), аналогичных проблемам двойного прохождения при on-a-stick подключении (подробнее — в [разделе 6.4.3](06.md)). --- [← Оглавление](../README.md) · [← Раздел 6: Места установки ТСПУ](06.md) · [Раздел 8: Формирование протокольных списков →](08.md)