From 73d1e3e642de55ceba9a47042b209055704075ae Mon Sep 17 00:00:00 2001 From: Daniel Lavrushin Date: Fri, 4 Sep 2026 12:09:36 +0200 Subject: [PATCH] Refine bypass documentation across multiple chapters - Enhanced descriptions of bypass functionality and operational modes in chapters 01, 02, and 03, clarifying the conditions under which bypasses operate and their impact on traffic. - Added details on the management and configuration of GL Sun optical bypasses in chapters 16, 21, and 22, including heartbeat packet handling and configuration parameters. - Updated the comparison of bypass mechanisms in chapter 22 to highlight differences between GL Sun and Silicom bypasses, emphasizing the operational implications for network operators. - Clarified the effects of switching modes on link stability and traffic filtering in chapter 24, ensuring accurate representation of operational practices. --- README.md | 6 +- chapters/01.md | 2 +- chapters/02.md | 2 +- chapters/03.md | 210 ++++++++++++++++++++++++++++--------------------- chapters/16.md | 12 +++ chapters/21.md | 2 +- chapters/22.md | 4 +- chapters/24.md | 2 +- 8 files changed, 143 insertions(+), 97 deletions(-) diff --git a/README.md b/README.md index 98c0021..7cf5530 100644 --- a/README.md +++ b/README.md @@ -34,13 +34,14 @@ - 3.2.2. Режим Inline — основной рабочий режим - 3.2.3. Режим TAP — копирование трафика без влияния на оператора - 3.2.4. Режим Active Bypass — замыкание без копирования - - 3.2.5. Режим Power-off Bypass — аварийное замыкание при обесточивании + - 3.2.5. Режим Passive Bypass — аварийное оптическое замыкание канала - 3.2.6. Переключение между режимами и влияние на оператора - 3.3. Байпасы GL Sun (пилотный проект, Урал) - - 3.3.1. Отличие от Silicom: только режим Power-off Bypass + - 3.3.1. Отличие от Silicom: только пассивный байпас - 3.3.2. Флап линков при каждом переключении - 3.4. Мониторинг каналов: Heartbeat-пакеты байпаса - 3.5. Автоматическое переключение в TAP/Active Bypass при потере канала +- 3.6. Развитие: отечественные байпасы ### [4. Балансировщик (EcoFilter Balancer)](chapters/04.md) @@ -210,6 +211,7 @@ - 16.4. Приоритет пулов - 16.5. Connection logging в пуле - 16.6. IPv6 в пуле +- 16.7. Секция bypass — heartbeat к байпасу GL Sun (только пилотный проект) ### [17. Фильтр: настройка DPI](chapters/17.md) diff --git a/chapters/01.md b/chapters/01.md index d2c081d..f6683c0 100644 --- a/chapters/01.md +++ b/chapters/01.md @@ -83,7 +83,7 @@ _Состав ТСПУ. Слева — абоненты и оборудован Скорость байпаса зависит от модели и установленных модулей: как правило, это **10 или 100 Гбит/с**; площадок с гигабитными линками мало. После байпасов все каналы приходят на балансировщики. -Байпас — последнее средство сохранить трафик оператора при отказе ТСПУ: при обесточивании оборудования он на физическом уровне замыкает каналы оператора напрямую, минуя остальные устройства ТСПУ (при этом у оператора возможны флапы линков). Режимы работы байпасов и их отличия для проектов описаны в [разделе 3](03.md). +Байпас — последнее средство сохранить трафик оператора при отказе ТСПУ: при обесточивании оборудования или при потере контроля пути через ТСПУ он замыкает каналы оператора напрямую, минуя остальные устройства ТСПУ (при обесточивании у оператора возможны флапы линков). Режимы работы байпасов, их отличия для проектов и переход на отечественные устройства описаны в [разделе 3](03.md). ### Балансировщики diff --git a/chapters/02.md b/chapters/02.md index cba466f..222aa4c 100644 --- a/chapters/02.md +++ b/chapters/02.md @@ -149,7 +149,7 @@ _Стык оператора: адреса и порты в прямом и об ### Этап 1: Байпас -Канал связи оператора физически разрывается и заводится на байпас: порты **Net0/Net1** смотрят в сторону оборудования оператора (LAN и WAN соответственно), порты **Mon0/Mon1** — в сторону балансировщика. В штатном режиме (Inline) байпас прозрачно пропускает трафик насквозь: Net0 → Mon0 в сторону балансировщика и Mon1 → Net1 обратно (и то же самое для другого направления). Байпас обеспечивает защиту канала: в случае аварии он замыкает линки напрямую, минуя остальное оборудование ТСПУ. У байпасов Silicom переключение между режимами Inline, TAP и Active Bypass для оператора безболезненно — теряются лишь пакеты, которые в момент переключения уже ушли в сторону балансировщика, но не успели вернуться (байпасы GL Sun пилотного проекта таких режимов не имеют и переключаются с флапом линка — [раздел 3.3](03.md)). +Канал связи оператора физически разрывается и заводится на байпас: порты **Net0/Net1** смотрят в сторону оборудования оператора (LAN и WAN соответственно), порты **Mon0/Mon1** — в сторону балансировщика. В штатном режиме (Inline) байпас прозрачно пропускает трафик насквозь: Net0 → Mon0 в сторону балансировщика и Mon1 → Net1 обратно (и то же самое для другого направления). Байпас обеспечивает защиту канала: при потере heartbeat-контроля до балансировщика, при пропадании линков Mon или при обесточивании он замыкает линки напрямую, минуя остальное оборудование ТСПУ. У байпасов Silicom переключение между режимами Inline, TAP и Active Bypass для оператора безболезненно — теряются лишь пакеты, которые в момент переключения уже ушли в сторону балансировщика, но не успели вернуться (байпасы GL Sun пилотного проекта таких режимов не имеют и переключаются с флапом линка — [раздел 3.3](03.md)). Байпас контролирует доступность канала до балансировщика служебными heartbeat-пакетами, которые отправляются из Mon0 и должны вернуться в Mon1 (и наоборот); до фильтров эти пакеты не доходят — балансировщик прозрачно заворачивает их обратно. Если heartbeat-пакеты перестают проходить, байпас автоматически переключает канал в режим TAP или Active Bypass. diff --git a/chapters/03.md b/chapters/03.md index a668fec..b4e9b7a 100644 --- a/chapters/03.md +++ b/chapters/03.md @@ -8,61 +8,66 @@ Байпас — это устройство, обеспечивающее **физическую защиту каналов связи оператора** при установке ТСПУ. Каналы связи оператора физически разрываются и заводятся на байпас, который в штатном режиме прозрачно пропускает трафик дальше — в сторону балансировщика и фильтров. -Основная задача байпаса — гарантировать, что **при любой аварии оборудования ТСПУ** (отказ фильтров, балансировщиков, обесточивание) связность сети оператора не будет нарушена. В аварийной ситуации байпас замыкает каналы оператора напрямую, минуя остальное оборудование ТСПУ. +Основная задача байпаса — гарантировать, что связность сети оператора не будет нарушена при тех авариях, которые байпас способен обнаружить: потеря пути через ТСПУ (по heartbeat-пакетам), пропадание линка на портах Mon, зависание подключённого inline-устройства и потеря питания. В такой ситуации байпас замыкает каналы оператора напрямую, минуя остальное оборудование ТСПУ; это последнее средство сохранить трафик оператора. При наличии балансировщика отказ отдельных фильтров байпас не отслеживает — его отрабатывает балансировщик программным байпасом группы портов ([раздел 4.6](04.md)); в схеме без балансировщика ([раздел 2.3](02.md)) контур heartbeat замыкается на самом фильтре, поэтому отказ или зависание фильтра байпас видит и замыкает канал. -Количество байпасов на площадке определяется **количеством линков оператора**, в разрыв которых устанавливается ТСПУ. Байпасы работают на скоростях **10–100 Гбит/с** (в отдельных случаях — 1 Гбит/с). +Количество байпасов на площадке определяется **исключительно количеством линков оператора**, в разрыв которых устанавливается ТСПУ: каждый канал занимает на байпасе свою четвёрку портов (сегмент), а одно устройство может обслуживать один или несколько каналов. Скорость байпаса зависит от модели и установленных модулей: как правило, это **10 или 100 Гбит/с**; площадок с гигабитными линками мало. Каждый байпас имеет management-интерфейс в сегменте управления площадки — под байпасы отведены первые 128 адресов management-подсети ([раздел 10.2](10.md)). -В проекте АСБИ используются два типа байпасов: +Термин «байпас» в документации ТСПУ используется в трёх значениях, которые важно различать: -| Проект | Производитель | Особенности | -| ------------------- | ------------- | ----------------------------------------------------- | -| **Федеральный** | Silicom | Полный набор режимов, безфлаповое переключение | -| **Пилотный (Урал)** | GL Sun | Только Power-off Bypass, флап линков при переключении | +- **аппаратный байпас** — само устройство (Silicom, GL Sun) и его режимы, физически замыкающие канал оператора; предмет этого раздела; +- **программный байпас** балансировщика — вывод из обработки отдельной группы портов в сторону фильтра при потере keep-alive или вручную, без участия аппаратного байпаса и без флапа линков у оператора ([раздел 4.6](04.md), [22.7](22.md)); +- **действие bypass** в правилах балансировщика — возврат определённого трафика оператору без анализа ([раздел 4.4](04.md), [21.7](21.md)). + +Ниже описано распределение оборудования на момент развёртывания федерального проекта; о более поздних поставках — см. [раздел 3.6](#36-развитие-отечественные-байпасы). В проекте АСБИ используются два типа аппаратных байпасов: + +| Проект | Производитель | Особенности | +| ------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Федеральный** | Silicom | Активное устройство с режимами Inline, TAP, Active Bypass и Passive Bypass; переключение между первыми тремя без флапа линков; собственные heartbeat-пакеты | +| **Пилотный (Урал)** | GL Sun | Оптический переключатель: только пропуск трафика или замыкание канала; каждое переключение — флап линков; heartbeat отправляет балансировщик (по TCP) или, на площадках без балансировщика, фильтр | ## 3.2. Байпасы Silicom (федеральный проект) Байпасы Silicom устанавливаются в рамках федерального проекта и обладают полным набором режимов работы, обеспечивающих гибкое управление прохождением трафика. +Аппаратно это 1U-шасси со сменными модулями. В 100G-шасси устанавливается до двух модулей, каждый обслуживает один сегмент (четвёрку портов). В 40G/10G-шасси — до трёх модулей: 40G-модуль даёт один сегмент, двухскоростной 10G/1G-модуль — два, то есть до трёх сегментов 40G или до шести сегментов 10G/1G на шасси. Порты Net выведены оптическими разъёмами MPO/LC, порты Mon — гнёздами под сменные трансиверы. Шасси имеет два резервированных блока питания (AC или −48 В DC) и управляется через консольный порт, Ethernet-порт управления (Telnet/SSH, web-интерфейс) и SNMP v1/v2c/v3 с отправкой trap-сообщений; все сегменты шасси управляются централизованно. + +В терминологии производителя режимы называются Inline (Normal), Bypass, Tap и Linkdrop. Принятые в ТСПУ названия **Active Bypass** и **Passive Bypass** соответствуют двум схемам обхода в архитектуре Silicom Double Bypass: активной (электронной, управляемой программно и по heartbeat) и пассивной (оптической, срабатывающей при пропадании питания или отказе активной электроники). Режим Linkdrop, в котором оба сетевых порта принудительно гасятся, имитируя отключение кабеля, в описанной здесь схеме работы ТСПУ не задействован. + ### 3.2.1. Порты: Net0/Net1 (оператор) и Mon0/Mon1 (балансировщик) Для каждого канала связи байпас Silicom имеет **четыре порта**: -- **Net0** и **Net1** — порты, подключаемые к оборудованию оператора (две стороны разорванного канала); -- **Mon0** и **Mon1** — порты, подключаемые к балансировщику (или напрямую к фильтру в простейшей конфигурации). +- **Net0** и **Net1** — порты, подключаемые к оборудованию оператора: Net0 — к стороне абонентов (LAN), Net1 — к стороне интернета (WAN); +- **Mon0** и **Mon1** — порты, подключаемые к балансировщику (или напрямую к фильтру в простейшей конфигурации): Mon0 — к LAN-порту линка, Mon1 — к WAN-порту. ```text - Оборудование Оборудование - оператора оператора - (сторона A) (сторона B) - │ │ - ▼ ▼ - ┌──────────────────────────┐ - │ Байпас Silicom │ - │ │ - │ Net0 Net1 │ - │ │ │ │ - │ │ (логика │ │ - │ │ режимов) │ │ - │ │ │ │ - │ Mon0 Mon1 │ - └────┬──────────────────┬──┘ - │ │ - ▼ ▼ - В сторону балансировщика + Оборудование оператора Оборудование оператора + (сторона абонентов, LAN) (сторона интернета, WAN) + │ │ + ┌────┴───────────────────────────────┴──────┐ + │ Net0 Net1 │ + │ Байпас Silicom (логика режимов) │ + │ Mon0 Mon1 │ + └────┬───────────────────────────────┬──────┘ + │ LAN │ WAN + Линк балансировщика (или пара портов фильтра) ``` +Все соединения двунаправленные: каждая пара Net/Mon — полнодуплексный проходной сегмент. Байпас Silicom — активное устройство: в режимах Inline, TAP и Active Bypass сигнал операторских линков принимается собственной оптикой модуля (порты Net выведены разъёмами MPO/LC), а линки Mon0/Mon1 — отдельные, со сменными трансиверами. Состояние линка между сторонами не транслируется: падение порта балансировщика или отключение патч-корда Mon оператор не увидит как link-down — байпас обнаружит это сам, по пропаданию линка на Mon-порту или по прекращению возврата heartbeat, и переведёт сегмент в режим обхода ([раздел 3.5](#35-автоматическое-переключение-в-tapactive-bypass-при-потере-канала)); падение линка оператора, наоборот, не видно на балансировщике. При диагностике нужно проверять состояние всех четырёх портов сегмента. В описании линка балансировщика рекомендуется указывать, к какому байпасу и какому его сегменту подключён линк ([раздел 21.4](21.md)). + ### 3.2.2. Режим Inline — основной рабочий режим **Inline** — основной рабочий режим байпаса. В этом режиме трафик прозрачно пропускается насквозь от оборудования оператора к балансировщику и обратно: -- Net0 → Mon0 (трафик от оператора к балансировщику) -- Mon1 → Net1 (обратный трафик) -- И симметрично для другого направления. +- Net0 → Mon0 (трафик от абонентов к балансировщику), Mon1 → Net1 (после обработки — в сторону интернета); +- и симметрично для обратного направления: Net1 → Mon1, Mon0 → Net0. ```text - Net0 ─────────────► Mon0 - ──► к балансировщику - Net1 ◄───────────── Mon1 + Оборудование оператора (LAN) Net0 ◄══════► Mon0 ◄══════► LAN-порт линка + Оборудование оператора (WAN) Net1 ◄══════► Mon1 ◄══════► WAN-порт линка + + путь абонент → интернет: Net0 → Mon0 → балансировщик → Mon1 → Net1 + обратный путь — зеркально ``` Весь трафик оператора проходит через ТСПУ и подвергается анализу и фильтрации. Это штатный режим работы при нормальном функционировании всего оборудования. @@ -72,17 +77,18 @@ **TAP** — режим зеркалирования (копирования) трафика. В этом режиме: 1. Каналы оператора **замыкаются напрямую** между собой (Net0 ↔ Net1); -2. **Копия трафика** отправляется в сторону балансировщика через порты Mon0/Mon1; -3. Обратный трафик от балансировщика **не принимается**. +2. **Копия трафика** отправляется в сторону балансировщика: входящий трафик порта Net0 зеркалируется на Mon0, входящий трафик порта Net1 — на Mon1; +3. Пользовательские кадры, приходящие от балансировщика на Mon0/Mon1, в канал оператора не передаются и **отбрасываются** — повлиять на трафик оператора ТСПУ не может. Собственные heartbeat-кадры байпас распознаёт и терминирует на себе, поэтому контроль пути через балансировщик продолжает работать и в режиме TAP. ```text Net0 ◄────────────► Net1 ← канал оператора замкнут │ │ - └──► Mon0 Mon1 ◄──┘ ← копия трафика - (только отправка) + └──► Mon0 Mon1 ◄──┘ ← копия трафика (Net0 → Mon0, Net1 → Mon1); + пользовательский приём с Mon-портов + отбрасывается (heartbeat — терминируется) ``` -В режиме TAP система фильтрации получает **полную копию** всего трафика оператора, но **никаким образом не может на него повлиять** — ни заблокировать, ни модифицировать. Это делает TAP идеальным **режимом отладки**: можно настраивать систему фильтрации, выявлять проблемы, проверять работу DPI — при полной гарантии, что операторский трафик не пострадает. +В режиме TAP система фильтрации получает **полную копию** всего трафика оператора, но **никаким образом не может на него повлиять** — ни заблокировать, ни модифицировать. Это очень удобный **режим отладки**: можно настраивать систему фильтрации и выявлять проблемы при полной гарантии, что операторский трафик не пострадает. ### 3.2.4. Режим Active Bypass — замыкание без копирования @@ -90,114 +96,126 @@ ```text Net0 ◄────────────► Net1 ← канал оператора замкнут - ← трафик к балансировщику НЕ идёт - Mon0 Mon1 - (неактивен) (неактивен) + ← операторский трафик к балансировщику НЕ идёт + Mon0 Mon1 ← линки up, heartbeat продолжается ``` -Каналы оператора замыкаются напрямую. ТСПУ полностью исключено из пути прохождения трафика. Этот режим используется, когда необходимо полностью отключить ТСПУ от обработки трафика, например, при проведении технических работ на оборудовании фильтрации. +Каналы оператора замыкаются активной электроникой байпаса, ТСПУ полностью исключено из пути прохождения трафика. Порты Mon0/Mon1 при этом остаются включёнными: линки в сторону балансировщика не падают, операторский трафик на них не подаётся, но heartbeat-пакеты продолжают отправляться — благодаря этому байпас обнаруживает восстановление пути через балансировщик и возвращается в Inline. Режим включается программно — по команде или автоматически при потере канала до балансировщика ([раздел 3.5](#35-автоматическое-переключение-в-tapactive-bypass-при-потере-канала)). -### 3.2.5. Режим Power-off Bypass — аварийное замыкание при обесточивании +### 3.2.5. Режим Passive Bypass — аварийное оптическое замыкание канала -**Power-off Bypass** — аварийный режим, в который байпас переходит автоматически при **отключении электропитания**. На физическом уровне (вероятно, оптический переключатель внутри оборудования) каналы замыкаются напрямую: +**Passive Bypass** — аварийный режим, в который байпас переходит автоматически при **отключении электропитания**, а также при отказе своей активной электроники (её контролирует внутренний сторожевой таймер). Каналы замыкаются на физическом уровне оптическим переключателем, который в обесточенном состоянии соединяет волокна Net0 и Net1 напрямую, минуя приёмопередатчики байпаса: ```text - Net0 ◄═══════════► Net1 ← физическое замыкание - ← оптический переключатель + Net0 ◄═══════════► Net1 ← физическое (оптическое) замыкание Mon0 Mon1 - (обесточены) (обесточены) + (отключены от канала оператора) ``` Это **последнее средство** защиты трафика оператора. При переключении в этот режим: -- у оператора **возможны флапы линков** (оптика «моргает»); +- у оператора **возможны флапы линков** (оптика «моргает»): устройства оператора начинают видеть друг друга напрямую и заново поднимают линк; - перерыв в трафике более существенный, чем при переключении между другими режимами; -- оператор почувствует переключение — может начать перестраиваться маршрутизация; +- оператор почувствует переключение — у него может начать перестраиваться маршрутизация; +- обратный переход в Inline — это **второй флап**: оптический тракт снова переключается с прямого соединения Net0 ↔ Net1 на приёмопередатчики байпаса; - последствия более негативные, но это **аварийный** случай. +Оптический бюджет для двух режимов считается по-разному. В режиме Inline каждая сторона оператора линкуется с сетевыми портами байпаса, поэтому бюджет — это своё плечо волокна плюс вносимые потери байпаса (по спецификации Silicom около 1–2 дБ; они присутствуют и в Inline, и в Passive Bypass). В режиме Passive Bypass устройства оператора линкуются напрямую друг с другом, и их трансиверы должны перекрывать сумму обоих плеч волокна плюс те же вносимые потери — это более жёсткое требование, и именно оно закладывается при проектировании стыка. Кроме того, на обеих сторонах канала должны стоять совместимые трансиверы: тип, длина волны, скорость и настройки FEC на 100G. + ### 3.2.6. Переключение между режимами и влияние на оператора -Ключевое преимущество байпасов Silicom — переключение между режимами **Inline**, **TAP** и **Active Bypass** происходит **безболезненно для оператора связи**: +Ключевое преимущество байпасов Silicom — переключение между режимами **Inline**, **TAP** и **Active Bypass** выполняется активной электроникой без изменения состояния оптических линков оператора и происходит **безболезненно для оператора связи**: - порты оператора **не флапают** (не падают); -- возможна лишь **кратковременная потеря единичных пакетов** — тех, которые уже ушли в сторону балансировщика, но не успели вернуться в момент переключения; -- такая потеря, как правило, **незаметна** ни для оператора, ни для абонентов — пропадание трафика на доли секунды восстанавливается протоколами верхних уровней модели OSI. +- при ручном переключении теряются лишь единичные пакеты — те, которые уже ушли в сторону балансировщика, но не успели вернуться в момент переключения; +- при автоматическом переключении к этому добавляется время обнаружения аварии — окно контроля возврата heartbeat (по умолчанию 20 мс, см. [раздел 3.4](#34-мониторинг-каналов-heartbeat-пакеты-байпаса)), в течение которого трафик канала не проходит; +- такие перерывы, как правило, **незаметны** ни для оператора, ни для абонентов — пропадание трафика на доли секунды восстанавливается протоколами верхних уровней. Сводная таблица режимов: -| Режим | Трафик оператора | Копия на ТСПУ | Влияние на оператора при переключении | -| ----------------- | ---------------- | ------------- | ------------------------------------- | -| **Inline** | Через ТСПУ | Да (полная) | — | -| **TAP** | Замкнут напрямую | Да (копия) | Безболезненно | -| **Active Bypass** | Замкнут напрямую | Нет | Безболезненно | -| **Power-off** | Замкнут напрямую | Нет | Флапы линков, перерыв трафика | +| Режим | Трафик оператора | Трафик на ТСПУ (Mon0/Mon1) | Линки Mon | Влияние на оператора при переключении | +| ------------------ | ---------------- | -------------------------------- | ------------------------ | ------------------------------------- | +| **Inline** | Через ТСПУ | Весь трафик, в разрыв | up, heartbeat идут | Без флапа при входе из TAP/Active Bypass; с флапом — при выходе из Passive Bypass | +| **TAP** | Замкнут напрямую | Копия (без приёма обратно) | up, heartbeat идут | Без флапа | +| **Active Bypass** | Замкнут напрямую | Нет | up, heartbeat идут | Без флапа | +| **Passive Bypass** | Замкнут напрямую | Нет | отключены от канала оператора (при обесточивании — down) | Флапы линков при входе и при возврате в Inline | ## 3.3. Байпасы GL Sun (пилотный проект, Урал) -Байпасы GL Sun используются в рамках **пилотного проекта на Урале**. По сравнению с Silicom, они значительно проще и имеют ряд существенных ограничений. +Байпасы GL Sun — оптические байпасы (производитель Guilin GLsun, КНР), используемые в рамках **пилотного проекта на Урале**. По сравнению с Silicom они значительно проще и имеют ряд существенных ограничений. -### 3.3.1. Отличие от Silicom: только режим Power-off Bypass +### 3.3.1. Отличие от Silicom: только пассивный байпас -Байпасы GL Sun поддерживают **только один механизм переключения** — эквивалент режима Power-off Bypass у Silicom. У них нет промежуточных режимов TAP или Active Bypass с безболезненным переключением. - -Фактически GL Sun умеет только: +Байпас GL Sun — это оптический переключатель без собственных сетевых портов: в устройствах этого класса одно 1U-шасси защищает от одной до четырёх линий, время оптического переключения — единицы миллисекунд (по спецификациям GLSUN менее 8–10 мс), управление — по RS-232 и Ethernet (web-интерфейс и командный протокол поверх TCP). В применённой в пилотном проекте конфигурации байпас поддерживает **только один механизм переключения** — оптическое замыкание канала, эквивалент режима Passive Bypass у Silicom; режимов TAP и Active Bypass с безболезненным переключением у него нет. Фактически GL Sun умеет только: - **пропускать трафик** через себя (аналог Inline); -- **замыкать каналы** физически (аналог Power-off Bypass). +- **замыкать канал** оптически (аналог Passive Bypass) — при пропадании питания, при прекращении heartbeat-пакетов или по команде. -При этом, в отличие от Silicom, байпасы GL Sun не генерируют heartbeat-пакеты самостоятельно. Вместо этого heartbeat-пакеты отправляются **балансировщиком** (или фильтром, если балансировщик отсутствует) в сторону GL Sun. На балансировщике или фильтре настраивается IP-адрес байпаса, интервал отправки heartbeat-пакетов и список линков байпаса, для которых выполняется проверка. +Требования к стыку те же, что и для пассивного обхода Silicom ([раздел 3.2.5](#325-режим-passive-bypass--аварийное-оптическое-замыкание-канала)): совместимые трансиверы с обеих сторон и запас оптического бюджета на вносимые потери переключателя. Для GL Sun это критичнее — прямое замыкание происходит при каждом переключении, а не только в аварии. -В федеральном проекте эта схема **не актуальна**, поскольку байпасы Silicom самостоятельно отправляют heartbeat-пакеты и самостоятельно проверяют доступность каналов. +Байпас GL Sun не генерирует heartbeat-пакеты самостоятельно — он работает как сторожевой таймер и лишь ожидает подтверждений от защищаемого устройства. Heartbeat-пакеты отправляет **балансировщик** (или **фильтр**, если балансировщика на площадке нет — на Урале есть несколько таких площадок), работая с байпасом в активном режиме. Обмен идёт по IP (TCP) на адрес байпаса через сеть управления, а не через порты данных, и байпас должен отвечать на эти пакеты; поэтому проверяется работоспособность самого балансировщика и сети управления, а не оптического пути через него: + +- на балансировщике задаются IPv4-адрес и порт байпаса, период отправки, группа балансировки, при активном состоянии которой отправляются heartbeat-пакеты, и список линков байпаса, для которых выполняется проверка (это сущности самого байпаса, например 01 и 02); дополнительно задаются тип сервиса и автоматический возврат трафика в основной режим после восстановления группы балансировки — не всегда полезная опция ([раздел 21.8](21.md)); +- на фильтре (площадки без балансировщика) аналогичная секция bypass в конфигурации задаёт IP-адрес байпаса, интервал отправки и список каналов ([раздел 16.7](16.md)). + +Состояние Bypass Watchdog держится в `active`, пока группа балансировки активна и байпас подтверждает приём. Если группа балансировки перешла в неактивное состояние, балансировщик перестаёт отправлять heartbeat-пакеты, состояние становится `disconnected`, и байпас оптически замыкает контролируемые линии ([раздел 22.7](22.md)). Обратная сторона такой схемы: авария в сегменте управления сама по себе приводит к аппаратному обходу и флапу линков оператора, хотя тракт обработки трафика исправен — это надо учитывать при работах в сети управления площадок с GL Sun. Следствие для пилотного проекта: при потере связи даже с одним фильтром вся площадка переводилась на аппаратный байпас с флапом линков у оператора, а для возврата площадки в работу требовалось заводить работы и повторный флап; в федеральном проекте программно байпасится только затронутая группа портов балансировщика, без переключения аппаратного байпаса ([раздел 4.6](04.md)). + +В федеральном проекте эта схема **не актуальна**: байпасы Silicom самостоятельно отправляют heartbeat-пакеты и самостоятельно проверяют доступность интерфейсов, поэтому логика работы с ними иная и на балансировщике для них ничего настраивать не нужно. ### 3.3.2. Флап линков при каждом переключении -Каждое переключение режима работы байпаса GL Sun — это **флап линков оператора**. Оптика «моргает», оператор связи видит падение и восстановление интерфейсов, что может приводить к: +Каждое переключение режима работы байпаса GL Sun — это **флап линков оператора**: оптический переключатель физически меняет пару соединённых трансиверов (оператор ↔ ТСПУ на оператор ↔ оператор), и даже при времени переключения менее 10 мс приёмники на стороне оператора фиксируют потерю и повторное появление сигнала. Оператор видит падение и восстановление интерфейсов, что может приводить к: - перестройке маршрутизации на стороне оператора; - заметному перерыву в прохождении трафика; -- срабатыванию мониторинга и генерации инцидентов у оператора. +- необходимости согласовывать возврат площадки в работу как плановые работы — с повторным флапом. -Это значительное неудобство по сравнению с байпасами Silicom, у которых переключение между режимами Inline, TAP и Active Bypass происходит прозрачно для оператора. +Безфлапового переключения, как у Silicom ([раздел 3.2.6](#326-переключение-между-режимами-и-влияние-на-оператора)), у GL Sun нет. ## 3.4. Мониторинг каналов: Heartbeat-пакеты байпаса -Байпас осуществляет **постоянный мониторинг доступности каналов** в сторону балансировщика с помощью специальных **heartbeat-пакетов**. +Байпас Silicom осуществляет **постоянный мониторинг доступности каналов** в сторону балансировщика с помощью специальных **heartbeat-пакетов**, которые генерирует сам, без участия внешнего программного обеспечения. -Принцип работы (для байпасов Silicom): +Принцип работы: -1. Байпас отправляет heartbeat-пакет из порта **Mon0**; -2. Пакет проходит через балансировщик (балансировщик пропускает heartbeat-пакеты прозрачно между своими портами); -3. Пакет должен дойти до порта **Mon1** (и аналогично в обратном направлении); -4. Если пакет проходит — байпас считает канал исправным и продолжает работу в текущем режиме. +1. Байпас отправляет heartbeat-пакет из порта **Mon0** (и одновременно — из порта **Mon1** в обратном направлении); +2. Пакет проходит через балансировщик: по требованию Silicom inline-устройство обязано прозрачно передать его с порта, подключённого к Mon0, на порт, подключённый к Mon1, и обратно — балансировщик делает это между парными портами линка без специальной настройки; +3. Пакет должен вернуться в порт **Mon1** (и, соответственно, Mon0); +4. Если пакеты проходят — байпас считает канал до балансировщика исправным и продолжает работать в режиме Inline. ```text - Байпас Балансировщик - ┌─────────┐ ┌──────────────────┐ - │ │ heartbeat │ │ - │ Mon0 ─┼─────────────► прозрачный │ - │ │ │ пропуск │ - │ Mon1 ◄┼──────────────┤ │ - │ │ heartbeat │ │ - └─────────┘ └──────────────────┘ + Байпас Балансировщик + ┌──────────┐ ┌──────────────────────┐ + │ Mon0 ───┼──── heartbeat ──►│ LAN-порт линка │ + │ │ │ │ │ + │ │ │ мост между парными │ + │ │ │ портами │ + │ │ │ ▼ │ + │ Mon1 ◄──┼──── heartbeat ───┤ WAN-порт линка │ + └──────────┘ └──────────────────────┘ + + Зеркальный контур: Mon1 → WAN-порт → LAN-порт → Mon0 ``` -Heartbeat-пакеты байпаса Silicom — это **не IP-пакеты**, а специальные служебные кадры (по умолчанию формат IPX). По запросу RDP.ru формат пакета был изменён на согласованный вариант, который прозрачно проходит через балансировщик и, при необходимости, через фильтр, не вызывая проблем с обработкой (фильтр пропускает не-IP-пакеты прозрачно). +По документации Silicom heartbeat-пакеты по умолчанию отправляются каждые 5 мс, а окно контроля составляет 20 мс; оба параметра настраиваются: интервал от 3 мс до 10 с, окно контроля от 10 мс до 50 с. -Важно: heartbeat-пакеты байпаса **не доходят до фильтров** при наличии балансировщика — они заворачиваются обратно на уровне балансировщика. Таким образом, существуют **две независимые стадии** проверки отказоустойчивости: +Heartbeat-пакеты байпаса Silicom — это **не IP-пакеты**, а небольшие служебные Ethernet-кадры с не-IP типом; формат кадра задаётся в настройках байпаса. Формат по умолчанию — IPX; по запросу RDP.ru на устанавливаемых байпасах он заменяется на согласованный с разработчиком балансировщика вариант, прохождение которого проверялось на стендовых тестах. Поскольку это не IP-пакет, балансировщик не хэширует его и не отправляет на фильтры, а прозрачно передаёт в парный порт линка; в схеме без балансировщика ([раздел 2.3](02.md)) то же самое делает фильтр — не-IP-пакеты он пропускает в парный порт без обработки, и контур проверки замыкается на фильтре. + +Важно: при наличии балансировщика heartbeat-пакеты байпаса **не доходят до фильтров** — они заворачиваются обратно на уровне балансировщика. Таким образом, существуют **две независимые стадии** проверки отказоустойчивости: 1. **Байпас → Балансировщик** — heartbeat-пакеты байпаса проверяют доступность каналов до балансировщика; -2. **Балансировщик → Фильтр** — keep-alive пакеты балансировщика проверяют доступность фильтров (подробнее — в [разделе 4](04.md)). +2. **Балансировщик → Фильтр** — keep-alive-пакеты балансировщика проверяют доступность и работоспособность фильтров (подробнее — в [разделе 4.6](04.md)). ## 3.5. Автоматическое переключение в TAP/Active Bypass при потере канала -Если heartbeat-пакеты, отправленные через Mon0, не доходят до Mon1 в течение определённого времени (настраиваемый порог), байпас считает, что **канал связи до балансировщика неисправен**. +Если heartbeat-пакеты, отправленные через Mon0, не возвращаются в Mon1 (или наоборот) в течение окна контроля, байпас считает, что **канал связи до балансировщика неисправен**. Кроме потери heartbeat, байпас уходит в обход при пропадании линка на Mon-портах, при зависании подключённого inline-устройства и по команде оператора. В этом случае байпас **автоматически переключает** данный канал в безопасный режим: - **TAP** — если требуется сохранить копирование трафика для диагностики; - **Active Bypass** — если требуется полностью исключить ТСПУ из пути трафика. -Выбор режима зависит от **настроек** конкретного байпаса. +Выбор режима зависит от **настроек** конкретного байпаса. В обоих случаях переключение проходит без флапа линков у оператора. Heartbeat-пакеты продолжают отправляться и в этих режимах: когда путь через балансировщик восстанавливается и heartbeat снова начинают возвращаться, байпас автоматически возвращается в Inline. После подачи питания байпас стартует в режиме обхода и переходит в Inline только после того, как heartbeat-пакеты начинают возвращаться. ```text Штатная работа (Inline): @@ -206,10 +224,22 @@ Heartbeat-пакеты байпаса Silicom — это **не IP-пакеты* Потеря канала → автоматическое переключение: Net0 ◄────────────► Net1 ← замыкание - (± копия на Mon0/Mon1, в зависимости от настроек) + (± копия на Mon0/Mon1, в зависимости от настроек; heartbeat продолжаются) ``` -Такое автоматическое переключение обеспечивает **защиту трафика оператора** без ручного вмешательства: если что-то случится с балансировщиком или фильтрами, каналы оператора будут замкнуты напрямую, и связность сети сохранится. +Такое автоматическое переключение обеспечивает **защиту трафика оператора** без ручного вмешательства: если выйдет из строя балансировщик или канал между байпасом и балансировщиком, каналы оператора будут замкнуты напрямую, и связность сети сохранится. При наличии балансировщика отказ отдельного фильтра байпас не видит — его обрабатывает балансировщик программным байпасом группы портов ([раздел 4.6.2](04.md)); в схеме без балансировщика контур heartbeat проходит через фильтр, поэтому его отказ приводит к переключению байпаса. + +Отдельно стоит помнить о возврате из **Passive Bypass**: он даёт второй флап линков оператора, поскольку оптический тракт снова переключается с прямого соединения Net0 ↔ Net1 на приёмопередатчики байпаса. Возврат площадки в работу после аварийного обхода поэтому согласуется с оператором как плановые работы. + +Побочный эффект возврата из байпаса в Inline: на фильтры сразу приходит большой объём трафика, и большинство сессий видны «с середины», без начального TCP SYN. Чтобы такие сессии заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN ([раздел 15.2.6](15.md)). + +## 3.6. Развитие: отечественные байпасы + +По открытым данным, с 2022 года Silicom прекратил техническую поддержку своего оборудования для ТСПУ, и для проекта был разработан отечественный байпас: разработчиком решения называют компанию «Булат», программное обеспечение — RDP.ru, аппаратную часть — АО «Сигналтек». С 2023 года также тестируются оптические переключатели российского производства, созданные по заказу Роскомнадзора. + +В каталоге «Сигналтек» этому классу устройств соответствует байпас **SP100G4M «СигналПасс»**; прямое отождествление именно этой модели с поставляемым в ТСПУ устройством открытыми источниками не подтверждается. По описанию производителя, SP100G4M — это 1U-шасси с установкой до четырёх полнодуплексных модулей 10/40/100G, с резервируемыми блоками питания, сменными модулями вентиляторов и «горячей заменой» модулей, блоков питания и вентиляторов; коммутационная матрица — Intel Tofino, работоспособность внутреннего контура (DPI) контролируется периодической отправкой keep-alive. Заявленные режимы работы соответствуют привычной модели: **в линии** — аналог Inline, **байпас** — программный обход (аналог Active Bypass), **сниффер (TAP)** — аналог TAP. Наличие пассивного оптического замыкания при обесточивании по опубликованным характеристикам не подтверждается и уточняется по эксплуатационной документации конкретной поставки; влияние переключений на линки оператора в открытых источниках также не описано. + +Ранее установленные байпасы Silicom и GL Sun при этом остаются в эксплуатации, и описанные выше режимы для них актуальны. --- diff --git a/chapters/16.md b/chapters/16.md index 5db3619..6f4aa46 100644 --- a/chapters/16.md +++ b/chapters/16.md @@ -187,6 +187,18 @@ ACL (Access Control List) — это набор правил, определяю - исключить определённые диапазоны из обработки; - полностью отключить обработку IPv6-трафика в рамках данного пула. +## 16.7. Секция bypass — heartbeat к байпасу GL Sun (только пилотный проект) + +В конфигурации фильтра есть секция **bypass**, которая в федеральном проекте **не используется**. Она была нужна на пилотном проекте на Урале для площадок, где балансировщика нет и фильтр подключён к оптическому байпасу GL Sun напрямую: такой байпас сам heartbeat-пакеты не генерирует, и отправлять их на байпас должен фильтр. В секции задаются: + +| Параметр | Описание | +| ------------------------- | --------------------------------------------------------------- | +| **IP-адрес байпаса** | Адрес байпаса GL Sun, на который фильтр отправляет heartbeat | +| **Интервал отправки** | Период отправки heartbeat-пакетов | +| **Список каналов** | Каналы (линки) байпаса, по которым выполняется проверка | + +На Урале осталось несколько площадок с такой схемой. С байпасами Silicom, которые сами отправляют heartbeat-пакеты и сами проверяют доступность каналов, секция не нужна (подробнее о байпасах — в [разделе 3.3](03.md); аналогичная настройка на балансировщике — в [разделе 21.8](21.md)). + --- ### Диагностическая заметка: `show cps` показывает ноль diff --git a/chapters/21.md b/chapters/21.md index f3fce80..4a63f9d 100644 --- a/chapters/21.md +++ b/chapters/21.md @@ -429,7 +429,7 @@ Match-условия можно использовать как для **вкл | --------------------------- | --------------------------------------------------------------- | | **IPv4-адрес байпаса** | IP-адрес байпаса GL Sun | | **Порт** | Порт для heartbeat-протокола | -| **Период отсылки** | Интервал отправки heartbeat (в наносекундах, например, 30 мкс) | +| **Период отсылки** | Интервал отправки heartbeat (в конфигурации задаётся в наносекундах; фактические единицы стоит проверить по документации балансировщика) | | **Группа балансировки** | Группа, для которой работает отправка heartbeat | | **Список линков байпаса** | Идентификаторы сущностей на стороне байпаса GL Sun | | **ToS** | Тип сервиса в IP-заголовке heartbeat-пакетов | diff --git a/chapters/22.md b/chapters/22.md index 5a52051..6249375 100644 --- a/chapters/22.md +++ b/chapters/22.md @@ -227,13 +227,15 @@ ### Преимущества перед переключением на байпасе -| Критерий | Bypass на оптическом байпасе | Программный bypass на балансировщике | +| Критерий | Bypass на оптическом байпасе GL Sun (пилотный проект) | Программный bypass на балансировщике | | -------------------------- | ------------------------------------- | --------------------------------------- | | **Флап линков оператора** | Да — при каждом переключении | **Нет** — физические линки не затрагиваются | | **Гранулярность** | Вся площадка целиком | **Каждая пара портов** индивидуально | | **Согласование с оператором** | Требуется (работы, окна обслуживания) | **Не требуется** — оператор ничего не замечает | | **Последствия** | Весь трафик не фильтруется | Не фильтруется **только часть** трафика | +> **Примечание:** сравнение приведено для оптического байпаса GL Sun. У байпасов Silicom переключение сегмента в TAP или Active Bypass выполняется без флапа линков и применяется к отдельному каналу, однако оно так же полностью снимает канал с фильтрации — см. [раздел 3.2.6](03.md). + > **Опыт эксплуатации:** такое поведение было опробовано при тестировании эшелонированной системы в Сургуте. Вместо переключения трафика на оптическом байпасе (что вызывает флапы линков и недовольство оператора) использовался программный bypass на балансировщике — одной командой трафик уводился с фильтров без каких-либо видимых последствий для оператора. ### Автоматическое восстановление diff --git a/chapters/24.md b/chapters/24.md index 3f727bf..36441d6 100644 --- a/chapters/24.md +++ b/chapters/24.md @@ -148,7 +148,7 @@ ### Bypass на оптическом байпасе -Переключение оптического байпаса в режим bypass/TAP — более радикальный метод, который **вызывает флапы линков** у оператора. Используется в крайнем случае и, как правило, требует согласования с оператором. +Переключение на самом байпасе — более радикальный метод: он полностью снимает канал с фильтрации. У байпасов **Silicom** перевод сегмента в TAP или Active Bypass выполняется **без флапа линков** оператора — теряются лишь пакеты, находившиеся в этот момент внутри ТСПУ (см. [раздел 3.2.6](03.md)). У оптических байпасов **GL Sun** любое переключение **вызывает флапы линков** и, как правило, требует согласования с оператором (см. [раздел 3.3.2](03.md)). ### Интерпретация результатов