217 lines
19 KiB
Markdown
217 lines
19 KiB
Markdown
# 3. Байпас (Bypass)
|
||
|
||
[← Оглавление](README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md)
|
||
|
||
---
|
||
|
||
## 3.1. Назначение и роль байпаса в ТСПУ
|
||
|
||
Байпас — это устройство, обеспечивающее **физическую защиту каналов связи оператора** при установке ТСПУ. Каналы связи оператора физически разрываются и заводятся на байпас, который в штатном режиме прозрачно пропускает трафик дальше — в сторону балансировщика и фильтров.
|
||
|
||
Основная задача байпаса — гарантировать, что **при любой аварии оборудования ТСПУ** (отказ фильтров, балансировщиков, обесточивание) связность сети оператора не будет нарушена. В аварийной ситуации байпас замыкает каналы оператора напрямую, минуя остальное оборудование ТСПУ.
|
||
|
||
Количество байпасов на площадке определяется **количеством линков оператора**, в разрыв которых устанавливается ТСПУ. Байпасы работают на скоростях **10–100 Гбит/с** (в отдельных случаях — 1 Гбит/с).
|
||
|
||
В проекте АСБИ используются два типа байпасов:
|
||
|
||
| Проект | Производитель | Особенности |
|
||
| ------------------- | ------------- | ----------------------------------------------------- |
|
||
| **Федеральный** | Silicom | Полный набор режимов, безфлаповое переключение |
|
||
| **Пилотный (Урал)** | GL Sun | Только Power-off Bypass, флап линков при переключении |
|
||
|
||
## 3.2. Байпасы Silicom (федеральный проект)
|
||
|
||
Байпасы Silicom устанавливаются в рамках федерального проекта и обладают полным набором режимов работы, обеспечивающих гибкое управление прохождением трафика.
|
||
|
||
### 3.2.1. Порты: Net0/Net1 (оператор) и Mon0/Mon1 (балансировщик)
|
||
|
||
Для каждого канала связи байпас Silicom имеет **четыре порта**:
|
||
|
||
- **Net0** и **Net1** — порты, подключаемые к оборудованию оператора (две стороны разорванного канала);
|
||
- **Mon0** и **Mon1** — порты, подключаемые к балансировщику (или напрямую к фильтру в простейшей конфигурации).
|
||
|
||
```text
|
||
Оборудование Оборудование
|
||
оператора оператора
|
||
(сторона A) (сторона B)
|
||
│ │
|
||
▼ ▼
|
||
┌──────────────────────────┐
|
||
│ Байпас Silicom │
|
||
│ │
|
||
│ Net0 Net1 │
|
||
│ │ │ │
|
||
│ │ (логика │ │
|
||
│ │ режимов) │ │
|
||
│ │ │ │
|
||
│ Mon0 Mon1 │
|
||
└────┬──────────────────┬──┘
|
||
│ │
|
||
▼ ▼
|
||
В сторону балансировщика
|
||
```
|
||
|
||
### 3.2.2. Режим Inline — основной рабочий режим
|
||
|
||
**Inline** — основной рабочий режим байпаса. В этом режиме трафик прозрачно пропускается насквозь от оборудования оператора к балансировщику и обратно:
|
||
|
||
- Net0 → Mon0 (трафик от оператора к балансировщику)
|
||
- Mon1 → Net1 (обратный трафик)
|
||
- И симметрично для другого направления.
|
||
|
||
```text
|
||
Net0 ─────────────► Mon0
|
||
──► к балансировщику
|
||
Net1 ◄───────────── Mon1
|
||
```
|
||
|
||
Весь трафик оператора проходит через ТСПУ и подвергается анализу и фильтрации. Это штатный режим работы при нормальном функционировании всего оборудования.
|
||
|
||
### 3.2.3. Режим TAP — копирование трафика без влияния на оператора
|
||
|
||
**TAP** — режим зеркалирования (копирования) трафика. В этом режиме:
|
||
|
||
1. Каналы оператора **замыкаются напрямую** между собой (Net0 ↔ Net1);
|
||
2. **Копия трафика** отправляется в сторону балансировщика через порты Mon0/Mon1;
|
||
3. Обратный трафик от балансировщика **не принимается**.
|
||
|
||
```text
|
||
Net0 ◄────────────► Net1 ← канал оператора замкнут
|
||
│ │
|
||
└──► Mon0 Mon1 ◄──┘ ← копия трафика
|
||
(только отправка)
|
||
```
|
||
|
||
В режиме TAP система фильтрации получает **полную копию** всего трафика оператора, но **никаким образом не может на него повлиять** — ни заблокировать, ни модифицировать. Это делает TAP идеальным **режимом отладки**: можно настраивать систему фильтрации, выявлять проблемы, проверять работу DPI — при полной гарантии, что операторский трафик не пострадает.
|
||
|
||
### 3.2.4. Режим Active Bypass — замыкание без копирования
|
||
|
||
**Active Bypass** — режим чистого обхода. Практически идентичен режиму TAP, за исключением того, что **копия трафика в сторону балансировщика не отправляется**:
|
||
|
||
```text
|
||
Net0 ◄────────────► Net1 ← канал оператора замкнут
|
||
← трафик к балансировщику НЕ идёт
|
||
Mon0 Mon1
|
||
(неактивен) (неактивен)
|
||
```
|
||
|
||
Каналы оператора замыкаются напрямую. ТСПУ полностью исключено из пути прохождения трафика. Этот режим используется, когда необходимо полностью отключить ТСПУ от обработки трафика, например, при проведении технических работ на оборудовании фильтрации.
|
||
|
||
### 3.2.5. Режим Power-off Bypass — аварийное замыкание при обесточивании
|
||
|
||
**Power-off Bypass** — аварийный режим, в который байпас переходит автоматически при **отключении электропитания**. На физическом уровне (вероятно, оптический переключатель внутри оборудования) каналы замыкаются напрямую:
|
||
|
||
```text
|
||
Net0 ◄═══════════► Net1 ← физическое замыкание
|
||
← оптический переключатель
|
||
Mon0 Mon1
|
||
(обесточены) (обесточены)
|
||
```
|
||
|
||
Это **последнее средство** защиты трафика оператора. При переключении в этот режим:
|
||
|
||
- у оператора **возможны флапы линков** (оптика «моргает»);
|
||
- перерыв в трафике более существенный, чем при переключении между другими режимами;
|
||
- оператор почувствует переключение — может начать перестраиваться маршрутизация;
|
||
- последствия более негативные, но это **аварийный** случай.
|
||
|
||
### 3.2.6. Переключение между режимами и влияние на оператора
|
||
|
||
Ключевое преимущество байпасов Silicom — переключение между режимами **Inline**, **TAP** и **Active Bypass** происходит **безболезненно для оператора связи**:
|
||
|
||
- порты оператора **не флапают** (не падают);
|
||
- возможна лишь **кратковременная потеря единичных пакетов** — тех, которые уже ушли в сторону балансировщика, но не успели вернуться в момент переключения;
|
||
- такая потеря, как правило, **незаметна** ни для оператора, ни для абонентов — пропадание трафика на доли секунды восстанавливается протоколами верхних уровней модели OSI.
|
||
|
||
Сводная таблица режимов:
|
||
|
||
| Режим | Трафик оператора | Копия на ТСПУ | Влияние на оператора при переключении |
|
||
| ----------------- | ---------------- | ------------- | ------------------------------------- |
|
||
| **Inline** | Через ТСПУ | Да (полная) | — |
|
||
| **TAP** | Замкнут напрямую | Да (копия) | Безболезненно |
|
||
| **Active Bypass** | Замкнут напрямую | Нет | Безболезненно |
|
||
| **Power-off** | Замкнут напрямую | Нет | Флапы линков, перерыв трафика |
|
||
|
||
## 3.3. Байпасы GL Sun (пилотный проект, Урал)
|
||
|
||
Байпасы GL Sun используются в рамках **пилотного проекта на Урале**. По сравнению с Silicom, они значительно проще и имеют ряд существенных ограничений.
|
||
|
||
### 3.3.1. Отличие от Silicom: только режим Power-off Bypass
|
||
|
||
Байпасы GL Sun поддерживают **только один механизм переключения** — эквивалент режима Power-off Bypass у Silicom. У них нет промежуточных режимов TAP или Active Bypass с безболезненным переключением.
|
||
|
||
Фактически GL Sun умеет только:
|
||
|
||
- **пропускать трафик** через себя (аналог Inline);
|
||
- **замыкать каналы** физически (аналог Power-off Bypass).
|
||
|
||
При этом, в отличие от Silicom, байпасы GL Sun не генерируют heartbeat-пакеты самостоятельно. Вместо этого heartbeat-пакеты отправляются **балансировщиком** (или фильтром, если балансировщик отсутствует) в сторону GL Sun. На балансировщике или фильтре настраивается IP-адрес байпаса, интервал отправки heartbeat-пакетов и список линков байпаса, для которых выполняется проверка.
|
||
|
||
В федеральном проекте эта схема **не актуальна**, поскольку байпасы Silicom самостоятельно отправляют heartbeat-пакеты и самостоятельно проверяют доступность каналов.
|
||
|
||
### 3.3.2. Флап линков при каждом переключении
|
||
|
||
Каждое переключение режима работы байпаса GL Sun — это **флап линков оператора**. Оптика «моргает», оператор связи видит падение и восстановление интерфейсов, что может приводить к:
|
||
|
||
- перестройке маршрутизации на стороне оператора;
|
||
- заметному перерыву в прохождении трафика;
|
||
- срабатыванию мониторинга и генерации инцидентов у оператора.
|
||
|
||
Это значительное неудобство по сравнению с байпасами Silicom, у которых переключение между режимами Inline, TAP и Active Bypass происходит прозрачно для оператора.
|
||
|
||
## 3.4. Мониторинг каналов: Heartbeat-пакеты байпаса
|
||
|
||
Байпас осуществляет **постоянный мониторинг доступности каналов** в сторону балансировщика с помощью специальных **heartbeat-пакетов**.
|
||
|
||
Принцип работы (для байпасов Silicom):
|
||
|
||
1. Байпас отправляет heartbeat-пакет из порта **Mon0**;
|
||
2. Пакет проходит через балансировщик (балансировщик пропускает heartbeat-пакеты прозрачно между своими портами);
|
||
3. Пакет должен дойти до порта **Mon1** (и аналогично в обратном направлении);
|
||
4. Если пакет проходит — байпас считает канал исправным и продолжает работу в текущем режиме.
|
||
|
||
```text
|
||
Байпас Балансировщик
|
||
┌─────────┐ ┌──────────────────┐
|
||
│ │ heartbeat │ │
|
||
│ Mon0 ─┼─────────────► прозрачный │
|
||
│ │ │ пропуск │
|
||
│ Mon1 ◄┼──────────────┤ │
|
||
│ │ heartbeat │ │
|
||
└─────────┘ └──────────────────┘
|
||
```
|
||
|
||
Heartbeat-пакеты байпаса Silicom — это **не IP-пакеты**, а специальные служебные кадры (по умолчанию формат IPX). По запросу RDP.ru формат пакета был изменён на согласованный вариант, который прозрачно проходит через балансировщик и, при необходимости, через фильтр, не вызывая проблем с обработкой (фильтр пропускает не-IP-пакеты прозрачно).
|
||
|
||
Важно: heartbeat-пакеты байпаса **не доходят до фильтров** при наличии балансировщика — они заворачиваются обратно на уровне балансировщика. Таким образом, существуют **две независимые стадии** проверки отказоустойчивости:
|
||
|
||
1. **Байпас → Балансировщик** — heartbeat-пакеты байпаса проверяют доступность каналов до балансировщика;
|
||
2. **Балансировщик → Фильтр** — keep-alive пакеты балансировщика проверяют доступность фильтров (подробнее — в [разделе 4](04.md)).
|
||
|
||
## 3.5. Автоматическое переключение в TAP/Active Bypass при потере канала
|
||
|
||
Если heartbeat-пакеты, отправленные через Mon0, не доходят до Mon1 в течение определённого времени (настраиваемый порог), байпас считает, что **канал связи до балансировщика неисправен**.
|
||
|
||
В этом случае байпас **автоматически переключает** данный канал в безопасный режим:
|
||
|
||
- **TAP** — если требуется сохранить копирование трафика для диагностики;
|
||
- **Active Bypass** — если требуется полностью исключить ТСПУ из пути трафика.
|
||
|
||
Выбор режима зависит от **настроек** конкретного байпаса.
|
||
|
||
```text
|
||
Штатная работа (Inline):
|
||
Net0 ──► Mon0 ──► Балансировщик ──► Mon1 ──► Net1
|
||
heartbeat ✓
|
||
|
||
Потеря канала → автоматическое переключение:
|
||
Net0 ◄────────────► Net1 ← замыкание
|
||
(± копия на Mon0/Mon1, в зависимости от настроек)
|
||
```
|
||
|
||
Такое автоматическое переключение обеспечивает **защиту трафика оператора** без ручного вмешательства: если что-то случится с балансировщиком или фильтрами, каналы оператора будут замкнуты напрямую, и связность сети сохранится.
|
||
|
||
---
|
||
|
||
[← Оглавление](README.md) · [← Раздел 2: Прохождение трафика через ТСПУ](02.md) · [Раздел 4: Балансировщик →](04.md)
|