mirror of
https://github.com/DanielLavrushin/tspu-docs.git
synced 2026-09-22 22:47:59 +03:00
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.
This commit is contained in:
Daniel Lavrushin
@@ -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)
|
||||
|
||||
|
||||
+1
-1
@@ -83,7 +83,7 @@ _Состав ТСПУ. Слева — абоненты и оборудован
|
||||
|
||||
Скорость байпаса зависит от модели и установленных модулей: как правило, это **10 или 100 Гбит/с**; площадок с гигабитными линками мало. После байпасов все каналы приходят на балансировщики.
|
||||
|
||||
Байпас — последнее средство сохранить трафик оператора при отказе ТСПУ: при обесточивании оборудования он на физическом уровне замыкает каналы оператора напрямую, минуя остальные устройства ТСПУ (при этом у оператора возможны флапы линков). Режимы работы байпасов и их отличия для проектов описаны в [разделе 3](03.md).
|
||||
Байпас — последнее средство сохранить трафик оператора при отказе ТСПУ: при обесточивании оборудования или при потере контроля пути через ТСПУ он замыкает каналы оператора напрямую, минуя остальные устройства ТСПУ (при обесточивании у оператора возможны флапы линков). Режимы работы байпасов, их отличия для проектов и переход на отечественные устройства описаны в [разделе 3](03.md).
|
||||
|
||||
### Балансировщики
|
||||
|
||||
|
||||
+1
-1
@@ -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.
|
||||
|
||||
|
||||
+120
-90
@@ -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 при этом остаются в эксплуатации, и описанные выше режимы для них актуальны.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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` показывает ноль
|
||||
|
||||
+1
-1
@@ -429,7 +429,7 @@ Match-условия можно использовать как для **вкл
|
||||
| --------------------------- | --------------------------------------------------------------- |
|
||||
| **IPv4-адрес байпаса** | IP-адрес байпаса GL Sun |
|
||||
| **Порт** | Порт для heartbeat-протокола |
|
||||
| **Период отсылки** | Интервал отправки heartbeat (в наносекундах, например, 30 мкс) |
|
||||
| **Период отсылки** | Интервал отправки heartbeat (в конфигурации задаётся в наносекундах; фактические единицы стоит проверить по документации балансировщика) |
|
||||
| **Группа балансировки** | Группа, для которой работает отправка heartbeat |
|
||||
| **Список линков байпаса** | Идентификаторы сущностей на стороне байпаса GL Sun |
|
||||
| **ToS** | Тип сервиса в IP-заголовке heartbeat-пакетов |
|
||||
|
||||
+3
-1
@@ -227,13 +227,15 @@
|
||||
|
||||
### Преимущества перед переключением на байпасе
|
||||
|
||||
| Критерий | Bypass на оптическом байпасе | Программный bypass на балансировщике |
|
||||
| Критерий | Bypass на оптическом байпасе GL Sun (пилотный проект) | Программный bypass на балансировщике |
|
||||
| -------------------------- | ------------------------------------- | --------------------------------------- |
|
||||
| **Флап линков оператора** | Да — при каждом переключении | **Нет** — физические линки не затрагиваются |
|
||||
| **Гранулярность** | Вся площадка целиком | **Каждая пара портов** индивидуально |
|
||||
| **Согласование с оператором** | Требуется (работы, окна обслуживания) | **Не требуется** — оператор ничего не замечает |
|
||||
| **Последствия** | Весь трафик не фильтруется | Не фильтруется **только часть** трафика |
|
||||
|
||||
> **Примечание:** сравнение приведено для оптического байпаса GL Sun. У байпасов Silicom переключение сегмента в TAP или Active Bypass выполняется без флапа линков и применяется к отдельному каналу, однако оно так же полностью снимает канал с фильтрации — см. [раздел 3.2.6](03.md).
|
||||
|
||||
> **Опыт эксплуатации:** такое поведение было опробовано при тестировании эшелонированной системы в Сургуте. Вместо переключения трафика на оптическом байпасе (что вызывает флапы линков и недовольство оператора) использовался программный bypass на балансировщике — одной командой трафик уводился с фильтров без каких-либо видимых последствий для оператора.
|
||||
|
||||
### Автоматическое восстановление
|
||||
|
||||
+1
-1
@@ -148,7 +148,7 @@
|
||||
|
||||
### Bypass на оптическом байпасе
|
||||
|
||||
Переключение оптического байпаса в режим bypass/TAP — более радикальный метод, который **вызывает флапы линков** у оператора. Используется в крайнем случае и, как правило, требует согласования с оператором.
|
||||
Переключение на самом байпасе — более радикальный метод: он полностью снимает канал с фильтрации. У байпасов **Silicom** перевод сегмента в TAP или Active Bypass выполняется **без флапа линков** оператора — теряются лишь пакеты, находившиеся в этот момент внутри ТСПУ (см. [раздел 3.2.6](03.md)). У оптических байпасов **GL Sun** любое переключение **вызывает флапы линков** и, как правило, требует согласования с оператором (см. [раздел 3.3.2](03.md)).
|
||||
|
||||
### Интерпретация результатов
|
||||
|
||||
|
||||
Reference in New Issue
Block a user