Добавлены разделы 19, 20 и 21: обновление прошивки фильтра, аппаратная платформа балансировщика и его конфигурация. Включены команды для управления прошивками, настройки портов, линков и фильтров, а также описание внутренней архитектуры и принципов работы балансировщика.
This commit is contained in:
Daniel Lavrushin
90
10.md
Normal file
90
10.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# 10. Сегмент управления ТСПУ
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 9: Центральная система управления](09.md)
|
||||
|
||||
---
|
||||
|
||||
## 10.1. Адресация: 10.<регион>.<площадка>.0/24
|
||||
|
||||
Каждая площадка ТСПУ имеет собственный **сегмент управления** — выделенную подсеть для management-интерфейсов всех устройств. Адресация сегмента управления построена по единой схеме:
|
||||
|
||||
```text
|
||||
10.<регион>.<площадка>.0/24
|
||||
```
|
||||
|
||||
Где:
|
||||
|
||||
| Октет | Значение | Пример |
|
||||
| -------- | ------------------------------------- | --------------------------- |
|
||||
| Первый | Всегда `10` (частная адресация) | `10` |
|
||||
| Второй | Номер региона (всего ~88 в стране) | `77` (Москва) |
|
||||
| Третий | Номер площадки в данном регионе | `1`, `2`, `3`... |
|
||||
| Четвёртый | Адрес устройства в подсети /24 (256 адресов) | `0`–`254` |
|
||||
|
||||
Таким образом, для площадки в Москве management-адрес будет выглядеть как `10.77.<номер_площадки>.0/24`.
|
||||
|
||||
## 10.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД
|
||||
|
||||
Все 256 адресов подсети /24 распределяются между устройствами площадки по фиксированной схеме:
|
||||
|
||||
```text
|
||||
10.<регион>.<площадка>.0/24
|
||||
|
||||
┌────────────────────────────────────────────────────────────┐
|
||||
│ .1 – .128 │ Управление байпасами (128 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .131 – .140 │ Управление балансировщиками (10 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .141 – .150 │ BMC балансировщиков (10 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .151 – .190 │ Управление фильтрами (40 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .191 – .230 │ IPMI фильтров (40 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .231 – .235 │ SPFS (management + IPMI) (5 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .241 – .245 │ СПХД (management + IPMI) (5 шт.) │
|
||||
├─────────────────┼─────────────────────────────────────────┤
|
||||
│ .254 │ Шлюз по умолчанию (криптошлюз) │
|
||||
└────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
Основные группы устройств:
|
||||
|
||||
- **Байпасы** (.1–.128) — наибольший диапазон, поскольку количество байпасов определяется количеством каналов связи оператора и может быть значительным;
|
||||
- **Балансировщики** (.131–.140) — management-интерфейсы балансировщиков (микросервер);
|
||||
- **BMC балансировщиков** (.141–.150) — BMC (Baseboard Management Controller) — аналог IPMI у фильтров, позволяет управлять аппаратной частью балансировщика даже при выходе из строя основного управляющего модуля;
|
||||
- **Фильтры** (.151–.190) — management-интерфейсы фильтров;
|
||||
- **IPMI фильтров** (.191–.230) — интерфейсы IPMI (Intelligent Platform Management Interface) для аппаратного управления серверами фильтров;
|
||||
- **SPFS** (.231–.235) — серверы предварительного формирования списков;
|
||||
- **СПХД** (.241–.245) — серверы предварительного хранения данных (syslog-серверы), используемые для хранения системных журналов со всех устройств площадки.
|
||||
|
||||
## 10.3. Шлюз по умолчанию — криптошлюз «Континент»
|
||||
|
||||
Адрес **.254** в подсети управления закреплён за **криптошлюзом «Континент»**, который является **шлюзом по умолчанию** для всех устройств площадки.
|
||||
|
||||
```text
|
||||
Устройства площадки ТСПУ
|
||||
┌──────────────────────────┐
|
||||
│ Байпасы │
|
||||
│ Балансировщики │──── .254 ────► Криптошлюз ──── VPN ────► ЦСУ
|
||||
│ Фильтры │ «Континент»
|
||||
│ SPFS, СПХД │
|
||||
└──────────────────────────┘
|
||||
```
|
||||
|
||||
Криптошлюз устанавливает **VPN-соединение** через публичные интернет-каналы с аналогичным (но более мощным) криптошлюзом на стороне ЦСУ. Через этот VPN осуществляется весь management-трафик: доступ к устройствам, сбор логов, мониторинг, обновление ПО и загрузка списков фильтрации.
|
||||
|
||||
Каждая площадка ТСПУ связана **с обеими площадками ЦСУ** (основной и резервной), что обеспечивает отказоустойчивость управления.
|
||||
|
||||
## 10.4. Подсеть логирования (единая для всех ТСПУ)
|
||||
|
||||
Помимо основной подсети управления (/24), в сегменте управления присутствует **отдельная подсеть логирования**. Эта подсеть используется для лог-интерфейсов фильтров — выделенных высокопроизводительных интерфейсов (DPDK), через которые передаются журналы соединений (connection log).
|
||||
|
||||
Ключевая особенность: подсеть логирования **единая и одинаковая** для всех площадок ТСПУ по всей стране. Это допустимо, поскольку данная подсеть **не выходит за пределы** конкретной площадки — нет необходимости обращаться извне к лог-интерфейсам устройств. Лог-интерфейсы не имеют полноценного IP-стека и не обрабатывают входящие пакеты (невозможно их «пропинговать»), что сделано для повышения производительности.
|
||||
|
||||
Системное логирование (syslog) при этом отправляется **через management-интерфейс**, а не через лог-интерфейс. Журналы соединений (connection log) — напротив, по умолчанию отправляются через **лог-интерфейс** (DPDK). Все системные логи с устройств площадки сохраняются на **СПХД** (серверы предварительного хранения данных), что обеспечивает возможность ретроспективного анализа событий на фильтрах, балансировщиках и байпасах.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 9: Центральная система управления](09.md) · [Раздел 11: Фильтр: аппаратная платформа →](11.md)
|
||||
140
11.md
Normal file
140
11.md
Normal file
@@ -0,0 +1,140 @@
|
||||
# 11. Фильтр: аппаратная платформа
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md)
|
||||
|
||||
---
|
||||
|
||||
## 11.1. Младшая линейка: EcoFilter 2020/2040
|
||||
|
||||
Фильтры выпускаются в двух линейках. **Младшая линейка** включает модели:
|
||||
|
||||
| Модель | Количество 10G-интерфейсов для трафика |
|
||||
| ---------------- | -------------------------------------- |
|
||||
| **EcoFilter 20** | 2 × 10 Гбит/с |
|
||||
| **EcoFilter 40** | 4 × 10 Гбит/с |
|
||||
|
||||
Модели младшей линейки отличаются от старшей только количеством десятигигабитных интерфейсов для обработки трафика. Внутренняя архитектура, программное обеспечение и принципы работы — одинаковы.
|
||||
|
||||
## 11.2. Старшая линейка: EcoFilter 4080/4120/4160
|
||||
|
||||
**Старшая линейка** включает модели с большим количеством интерфейсов:
|
||||
|
||||
| Модель | Количество 10G-интерфейсов для трафика |
|
||||
| -------------------- | -------------------------------------- |
|
||||
| **EcoFilter 4080** | 8 × 10 Гбит/с |
|
||||
| **EcoFilter 4120** | 12 × 10 Гбит/с |
|
||||
| **EcoFilter 4160** | 16 × 10 Гбит/с |
|
||||
|
||||
Как видно из названий, номер модели напрямую связан с количеством интерфейсов: **40**80 → **8**×10G, **41**20 → **12**×10G, **41**60 → **16**×10G.
|
||||
|
||||
Все модели обеих линеек:
|
||||
|
||||
- монтируются в 19-дюймовую стойку, форм-фактор **1U**;
|
||||
- оснащены **двумя блоками питания** (постоянного или переменного тока), заменяемыми на горячую;
|
||||
- имеют **вентиляторы**, заменяемые на горячую;
|
||||
- имеют порты **Console**, **Management** и **лог-интерфейсы** на передней панели.
|
||||
|
||||
> **Примечание о производительности.** Маркетинговые материалы указывают производительность до 160 Гбит/с, однако эта цифра относится к функционалу NAT-трансляции, который в проекте ТСПУ не используется. Реальная производительность в режиме DPI-фильтрации существенно ниже и зависит от профиля трафика.
|
||||
|
||||
## 11.3. Модели 2019 года (пилотный проект, Урал)
|
||||
|
||||
Модели 2019 года установлены на **пилотном проекте** (Уральский регион) и продолжают там работать.
|
||||
|
||||
### 11.3.1. Процессоры Intel Xeon 2695/2699, 18/22 ядра, 128/256 ГБ RAM
|
||||
|
||||
| Параметр | EcoFilter 4080 | EcoFilter 4120 / 4160 |
|
||||
| ----------------------- | --------------------------- | --------------------------- |
|
||||
| **Процессор** | Intel Xeon 2695 | Intel Xeon 2699 |
|
||||
| **Количество ядер** | 18 | 22 |
|
||||
| **Оперативная память** | 128 ГБ | 256 ГБ |
|
||||
| **Накопитель** | SSD 32 ГБ | SSD 32 ГБ |
|
||||
| **Блоки питания** | 2 (AC или DC), hot-swap | 2 (AC или DC), hot-swap |
|
||||
|
||||
На передней панели расположены разъёмы Console, Management и лог-интерфейс. На задней панели — два медных логирующих порта и от 8 до 16 десятигигабитных интерфейсов для обработки трафика.
|
||||
|
||||
### 11.3.2. Фиксированные сетевые интерфейсы
|
||||
|
||||
В моделях 2019 года сетевые интерфейсы для обработки трафика **встроены** в платформу — заменить или поменять интерфейсные платы невозможно. Количество и тип портов определяются моделью на этапе производства.
|
||||
|
||||
## 11.4. Модели 2020 года (федеральный проект)
|
||||
|
||||
Модели 2020 года поставляются в рамках **федерального проекта** и имеют ряд улучшений по сравнению с моделями 2019 года.
|
||||
|
||||
### 11.4.1. Процессор Intel Xeon Gold 6212, 24 ядра, 192/384 ГБ RAM
|
||||
|
||||
| Параметр | EcoFilter 4080 | EcoFilter 4120 / 4160 |
|
||||
| ----------------------- | --------------------------- | --------------------------- |
|
||||
| **Процессор** | Intel Xeon Gold 6212 | Intel Xeon Gold 6212 |
|
||||
| **Количество ядер** | 24 | 24 |
|
||||
| **Оперативная память** | 192 ГБ | 384 ГБ |
|
||||
| **Накопитель** | SSD 32 ГБ | SSD 32 ГБ |
|
||||
| **Блоки питания** | 2 (AC или DC), hot-swap | 2 (AC или DC), hot-swap |
|
||||
|
||||
Процессор нового поколения (**Gold 6212** вместо серии 2695/2699) обеспечивает большее количество ядер (24 против 18/22) и поддержку большего объёма оперативной памяти.
|
||||
|
||||
### 11.4.2. Сменные сетевые интерфейсы, 4× SFP+ лог-порта
|
||||
|
||||
Ключевые отличия от моделей 2019 года:
|
||||
|
||||
- **Сменные сетевые интерфейсы** — интерфейсные платы для обработки трафика можно вытаскивать и заменять, что упрощает обслуживание и позволяет адаптировать конфигурацию под конкретную площадку;
|
||||
- **Лог-интерфейсы** — вместо двух медных портов на задней панели теперь **4 порта SFP+ (10 Гбит/с)** для логирования.
|
||||
|
||||
Поставщики аппаратных платформ для федерального проекта могут быть **разными** (например, стандартная «голубая» платформа RDP.ru или чёрные платформы от вендора Lanner), поэтому внешний вид может отличаться. Однако внутренняя аппаратная начинка и принципы работы остаются одинаковыми.
|
||||
|
||||
## 11.5. Разделение интерфейсов: LAN (чётные) / WAN (нечётные)
|
||||
|
||||
Все интерфейсы фильтра, предназначенные для обработки трафика, **строго разделены** на две группы:
|
||||
|
||||
```text
|
||||
Передняя панель фильтра (пример EcoFilter 4160)
|
||||
|
||||
┌──────────────────────────────────────────────────┐
|
||||
│ Console Mgmt Log │
|
||||
│ │
|
||||
│ Интерфейсы для трафика: │
|
||||
│ │
|
||||
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ... │
|
||||
│ │ 0 │ │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 │ │
|
||||
│ │LAN │ │WAN │ │LAN │ │WAN │ │LAN │ │WAN │ │
|
||||
│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │
|
||||
│ чёт. нечёт. чёт. нечёт. чёт. нечёт. │
|
||||
└──────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
| Тип порта | Нумерация | Направление |
|
||||
| --------- | ------------- | --------------------------------- |
|
||||
| **LAN** | Чётные (0, 2, 4, 6...) | В сторону абонентов (от балансировщика) |
|
||||
| **WAN** | Нечётные (1, 3, 5, 7...) | В сторону интернета (к балансировщику) |
|
||||
|
||||
Этот принцип чётных/нечётных портов **един** для всех моделей и поколений фильтров. Он же используется на балансировщиках EcoFilter Balancer (но **не соблюдается** на Eco Highway — подробнее в [разделе 7.4.1](07.md)).
|
||||
|
||||
Разделение LAN/WAN прослеживается через всё оборудование ТСПУ — от байпасов через балансировщики до фильтров. Это фундаментальный принцип архитектуры: трафик от абонентов всегда приходит со стороны LAN, трафик из интернета — со стороны WAN.
|
||||
|
||||
## 11.6. История платформы: от CGNAT (2013) к DPI-фильтру
|
||||
|
||||
Платформа фильтра имеет длительную историю развития, начавшуюся **в 2013 году** с устройства **CGNAT** (Carrier-Grade NAT), предназначенного для трансляции адресов у операторов связи. Поскольку платформа изначально создавалась для операторского применения, часть внутренней архитектуры (сессии, трансляции, понятия LAN/WAN) заточена под этот сценарий — что объясняет некоторые особенности, с которыми приходится сталкиваться при эксплуатации в режиме DPI-фильтра.
|
||||
|
||||
```text
|
||||
2013 CGNAT (трансляция адресов)
|
||||
│
|
||||
├──── URL-фильтрация
|
||||
│
|
||||
├──── PPPoE BRAS (не используется в проекте ТСПУ)
|
||||
│
|
||||
├──── Router (параллельная ветка, не используется)
|
||||
│
|
||||
└──── DPI (распознавание протоколов) ◄── используется в проекте ТСПУ
|
||||
```
|
||||
|
||||
Из всего доступного функционала платформы в проекте ТСПУ используются только **два модуля**:
|
||||
|
||||
| Модуль | Назначение |
|
||||
| -------------- | ------------------------------------------------------------- |
|
||||
| **EcoFilter** | Фильтрация трафика по спискам (реестр РКН, DPI-листы) |
|
||||
| **EcoDPI** | Распознавание трафика приложений вплоть до 7-го уровня модели OSI |
|
||||
|
||||
Остальной функционал (NAT, BRAS, QoS, маршрутизация) доступен в прошивке, но **не задействован** в проекте ТСПУ.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 10: Сегмент управления ТСПУ](10.md) · [Раздел 12: Сессии и трансляции на фильтре →](12.md)
|
||||
191
12.md
Normal file
191
12.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# 12. Сессии и трансляции на фильтре
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md)
|
||||
|
||||
---
|
||||
|
||||
## 12.1. Понятие сессии: local IP:port + global IP:port + remote IP:port
|
||||
|
||||
Вся обработка трафика на фильтре построена на понятии **сессии**. Сессия — это запись, описывающая конкретное соединение между абонентом и удалённым ресурсом. Каждая сессия содержит следующие поля:
|
||||
|
||||
```text
|
||||
<направление> <протокол> <local IP>:<port> <global IP>:<port> <remote IP>:<port> <время> <тайм-аут>
|
||||
```
|
||||
|
||||
| Поле | Описание |
|
||||
| ----------------- | ----------------------------------------------------------- |
|
||||
| **Направление** | Egress (от абонента) или Ingress (к абоненту) — по первому пакету |
|
||||
| **Протокол** | Протокол L4: TCP, UDP, ICMP |
|
||||
| **Local IP:port** | IP-адрес и порт абонента (серый, до NAT) |
|
||||
| **Global IP:port**| IP-адрес и порт после NAT-трансляции (белый) |
|
||||
| **Remote IP:port**| IP-адрес и порт удалённого ресурса в интернете |
|
||||
| **Время** | Время последнего пакета в рамках данной сессии |
|
||||
| **Тайм-аут** | Время, через которое сессия будет удалена при отсутствии трафика |
|
||||
|
||||
Сессия создаётся автоматически при прохождении первого пакета нового соединения через фильтр. Все последующие пакеты в рамках этого же соединения привязываются к уже существующей сессии.
|
||||
|
||||
## 12.2. Понятие трансляции: local IP:port ↔ global IP:port
|
||||
|
||||
**Трансляция** — это более простая сущность, описывающая связку между локальным (серым) адресом абонента и глобальным (белым) адресом из NAT-пула:
|
||||
|
||||
```text
|
||||
<local IP>:<port> ↔ <global IP>:<port>
|
||||
```
|
||||
|
||||
В отличие от сессии, трансляция **не содержит** remote-адреса. Это внутренняя абстракция фильтра, описывающая, каким образом транслируется адрес конкретного абонента.
|
||||
|
||||
Для просмотра трансляций используется команда `show xl` (в отличие от `show session` для сессий).
|
||||
|
||||
## 12.3. Режим без NAT: local = global
|
||||
|
||||
В проекте ТСПУ **NAT-трансляция не используется** — фильтр работает как прозрачное L2-устройство и не изменяет IP-адреса в пакетах. В этом режиме:
|
||||
|
||||
- **Local IP** всегда **совпадает** с **Global IP**;
|
||||
- Local port всегда совпадает с Global port;
|
||||
- Для IPv6-трафика NAT в принципе отсутствует.
|
||||
|
||||
```text
|
||||
Режим с NAT (не используется в ТСПУ):
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ Local IP │ ──► │ Global IP │ ──► │ Remote IP │
|
||||
│ 10.0.0.1:80 │ │ 203.0.113.5 │ │ 93.184.216.34│
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
|
||||
Режим без NAT (используется в ТСПУ):
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ Local IP │ = │ Global IP │ ──► │ Remote IP │
|
||||
│ 10.0.0.1:80 │ │ 10.0.0.1:80 │ │ 93.184.216.34│
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
```
|
||||
|
||||
Несмотря на то, что в режиме без NAT поля Local и Global дублируются, структура сессии остаётся прежней — это наследие архитектуры платформы, начинавшейся как CGNAT-устройство (подробнее — в [разделе 11.6](11.md)). На практике это означает, что команды фильтрации с ключевым словом `global` в нашем проекте **не имеют большого смысла** — достаточно использовать `local` и `remote`.
|
||||
|
||||
## 12.4. Направление сессии: Egress (от абонента) / Ingress (к абоненту)
|
||||
|
||||
Каждая сессия имеет **направление**, которое определяется **по первому пакету**, создавшему эту сессию:
|
||||
|
||||
| Направление | Первый пакет пришёл со стороны | Значение |
|
||||
| ----------- | ------------------------------ | --------------------------------- |
|
||||
| **Egress** | LAN-порт (абонент) | Абонент инициировал соединение |
|
||||
| **Ingress** | WAN-порт (интернет) | Соединение инициировано извне |
|
||||
|
||||
Направление фиксируется **один раз** в момент создания сессии и больше не меняется. Никакого другого смысла, кроме указания стороны первого пакета, у направления нет.
|
||||
|
||||
Типичный сценарий: абонент открывает веб-страницу — первый SYN-пакет приходит со стороны LAN, сессия создаётся как **Egress**. Если же к абоненту приходит входящее соединение из интернета — первый пакет приходит со стороны WAN, сессия создаётся как **Ingress**.
|
||||
|
||||
## 12.5. Принцип: локальный IP абонента всегда на первом месте
|
||||
|
||||
Независимо от направления трафика, фильтр **всегда записывает** локальный IP-адрес абонента в поле **Local IP** — первое поле адресов в сессии:
|
||||
|
||||
```text
|
||||
Пакет от абонента (LAN → WAN):
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Source IP: 10.0.0.1 → записывается в Local IP │
|
||||
│ Dest IP: 93.184.216.34 → записывается в Remote IP│
|
||||
└─────────────────────────────────────────────────────┘
|
||||
|
||||
Пакет к абоненту (WAN → LAN):
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Source IP: 93.184.216.34 → записывается в Remote IP│
|
||||
│ Dest IP: 10.0.0.1 → записывается в Local IP │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
То есть для пакетов со стороны LAN: Source IP → Local IP, Destination IP → Remote IP.
|
||||
Для пакетов со стороны WAN: поля **меняются местами** — Destination IP → Local IP, Source IP → Remote IP.
|
||||
|
||||
Это **крайне важный принцип** для траблшутинга. Если при просмотре сессий в поле Local IP появляются интернет-адреса (которые там быть не должны), это признак проблемы на пути прохождения трафика — например, **перепутки LAN/WAN** (подробнее — в [разделе 24.6](24.md)).
|
||||
|
||||
## 12.6. Связь трансляций и сессий: одна трансляция — много сессий
|
||||
|
||||
В рамках одной трансляции может существовать **несколько сессий**:
|
||||
|
||||
```text
|
||||
Трансляция (одна):
|
||||
10.0.0.1:12345 ↔ 10.0.0.1:12345
|
||||
|
||||
Сессия 1: 10.0.0.1:12345 → 93.184.216.34:443
|
||||
Сессия 2: 10.0.0.1:12345 → 151.101.1.69:443
|
||||
Сессия 3: 10.0.0.1:12345 → 104.16.132.229:80
|
||||
...
|
||||
Сессия N: 10.0.0.1:12345 → 8.8.8.8:53
|
||||
```
|
||||
|
||||
Логика жизненного цикла:
|
||||
|
||||
1. Проходит первый пакет нового соединения → создаётся **трансляция** и одновременно с ней первая **сессия**;
|
||||
2. Если с того же локального адреса и порта устанавливаются соединения к другим ресурсам → создаются **новые сессии** в рамках той же трансляции;
|
||||
3. Сессии удаляются индивидуально по своим тайм-аутам;
|
||||
4. Трансляция **удаляется только после того**, как умерла последняя сессия в её рамках.
|
||||
|
||||
Пример: один абонентский порт может иметь одну трансляцию и сотни связанных сессий к различным ресурсам.
|
||||
|
||||
## 12.7. Тайм-ауты сессий и трансляций
|
||||
|
||||
Тайм-ауты для сессий и трансляций задаются **раздельно** в секции NAT Defaults конфигурации фильтра (подробнее — в [разделе 15.3](15.md)):
|
||||
|
||||
- **Тайм-аут сессии** — время с момента последнего пакета, после которого сессия удаляется;
|
||||
- **Тайм-аут трансляции** — время с момента удаления последней связанной сессии, после которого удаляется сама трансляция.
|
||||
|
||||
Параметры тайм-аутов устанавливаются в секции NAT Defaults в качестве значений по умолчанию. При создании конкретного пула эти значения наследуются, но могут быть **переопределены** на уровне пула, если необходимо.
|
||||
|
||||
В выводе команды `show session` для каждой сессии отображаются:
|
||||
- **Время последнего пакета** — когда был последний пакет в рамках данной сессии;
|
||||
- **Оставшееся время жизни** — через сколько сессия будет удалена при отсутствии нового трафика.
|
||||
|
||||
## 12.8. Команды: `show session`, `show xl`, фильтрация по `local`/`remote`, pipe и count
|
||||
|
||||
### Основные команды
|
||||
|
||||
| Команда | Назначение |
|
||||
| ---------------- | ----------------------------------- |
|
||||
| `show session` | Просмотр таблицы сессий |
|
||||
| `show xl` | Просмотр таблицы трансляций |
|
||||
|
||||
### Фильтрация по адресам
|
||||
|
||||
Обе команды поддерживают фильтрацию по ключевым словам:
|
||||
|
||||
| Ключевое слово | Фильтрация по | Пример |
|
||||
| -------------- | ------------------------- | ----------------------------------------- |
|
||||
| `local` | Локальный IP-адрес | `show session local 10.0.0.1` |
|
||||
| `global` | Глобальный IP-адрес | В проекте ТСПУ не имеет смысла (= local) |
|
||||
| `remote` | Удалённый IP-адрес | `show session remote 93.184.216.34` |
|
||||
| `la` | Локальный IP + порт | `show session la 10.0.0.1:12345` |
|
||||
| `ga` | Глобальный IP + порт | В проекте ТСПУ не имеет смысла (= la) |
|
||||
| `ra` | Удалённый IP + порт | `show session ra 93.184.216.34:443` |
|
||||
|
||||
В контексте проекта ТСПУ (без NAT) наиболее полезны фильтры `local` и `remote`, поскольку `global` всегда дублирует `local`.
|
||||
|
||||
### Pipe-операторы
|
||||
|
||||
Результат вывода можно обработать через **pipe** (`|`), поддерживающий несколько операторов:
|
||||
|
||||
| Оператор | Назначение |
|
||||
| ----------- | ------------------------------------------------- |
|
||||
| `include` | Показать только строки, содержащие заданный паттерн |
|
||||
| `exclude` | Исключить строки, содержащие заданный паттерн |
|
||||
| `count` | Подсчитать количество строк в выводе |
|
||||
| `more` | Постраничный вывод |
|
||||
|
||||
Pipe-операторы можно **комбинировать последовательно**. Пример:
|
||||
|
||||
```text
|
||||
show session local 10.0.0.1 | include 6881 | count
|
||||
```
|
||||
|
||||
Эта команда выведет количество сессий абонента `10.0.0.1`, в которых присутствует порт `6881` (характерный для BitTorrent).
|
||||
|
||||
### Удалённый доступ к сессиям
|
||||
|
||||
API для удалённого доступа к данным фильтра отсутствует. Однако можно получить информацию удалённо через **SSH-команду**:
|
||||
|
||||
```text
|
||||
ssh admin@<IP-фильтра> "show session local 10.0.0.1"
|
||||
```
|
||||
|
||||
Соединение с фильтром устанавливается, команда выполняется, результат возвращается на терминал. Дальнейшая обработка выполняется средствами операционной системы (bash-скрипты, grep и т.д.). Внутренние pipe-операторы фильтра при удалённом вызове через SSH могут **не работать** — в этом случае следует использовать внешние средства обработки вывода.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 11: Фильтр: аппаратная платформа](11.md) · [Раздел 13: Фильтр: первоначальная настройка и CLI →](13.md)
|
||||
178
13.md
Normal file
178
13.md
Normal file
@@ -0,0 +1,178 @@
|
||||
# 13. Фильтр: первоначальная настройка и CLI
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md)
|
||||
|
||||
---
|
||||
|
||||
## 13.1. Подключение: консоль (115200 8N1) и SSH (порт 22)
|
||||
|
||||
Доступ к фильтру осуществляется двумя способами:
|
||||
|
||||
| Способ | Параметры |
|
||||
| -------------- | ------------------------------------------------ |
|
||||
| **Консоль** | 115200 бод, 8 бит данных, без паритета, 1 стоп-бит (8N1), контроль потока выключен |
|
||||
| **SSH** | Порт 22, стандартный доступ |
|
||||
|
||||
Расположение консольного порта на корпусе **отличается** в зависимости от модели и года выпуска — на каждом устройстве порт подписан. Настройки консоли стандартные и менять их необходимости нет.
|
||||
|
||||
## 13.2. Логин по умолчанию: admin / econat
|
||||
|
||||
При заводской прошивке на фильтре настроена учётная запись по умолчанию:
|
||||
|
||||
- **Логин:** `admin`
|
||||
- **Пароль:** `econat`
|
||||
|
||||
Данного пользователя можно удалить и создать новых (подробнее о настройке пользователей — в [разделе 14.4](14.md)).
|
||||
|
||||
## 13.3. Операционный режим (>) и конфигурационный режим (#)
|
||||
|
||||
CLI фильтра имеет **два режима** работы:
|
||||
|
||||
| Режим | Приглашение | Назначение |
|
||||
| ------------------------ | ----------- | --------------------------------------------------------- |
|
||||
| **Операционный** | `>` | Просмотр информации: команды `show`, мониторинг |
|
||||
| **Конфигурационный** | `#` | Изменение настроек, управление прошивками, перезагрузка |
|
||||
|
||||
Переход из операционного в конфигурационный режим выполняется командой **`config`**.
|
||||
|
||||
В операционном режиме доступны команды просмотра (`show session`, `show interface` и т.д.). В конфигурационном режиме доступны все команды изменения параметров, а также управление прошивками (`firmware`), перезагрузка устройства и другие административные операции.
|
||||
|
||||
## 13.4. Навигация по дереву конфигурации: system, pools, access-lists
|
||||
|
||||
Конфигурация фильтра организована в виде **дерева** с тремя основными разделами:
|
||||
|
||||
```text
|
||||
/ (корень)
|
||||
├── system ← все основные настройки устройства
|
||||
│ ├── mng-if ← management-интерфейс
|
||||
│ ├── serial ← консольный порт
|
||||
│ ├── terminal ← SSH-настройки
|
||||
│ ├── users ← пользователи
|
||||
│ ├── nat-defaults← параметры сессий, тайм-аутов
|
||||
│ ├── dpi ← настройки DPI
|
||||
│ └── ...
|
||||
├── pools ← пулы обработки трафика
|
||||
└── access-lists ← списки контроля доступа (ACL)
|
||||
```
|
||||
|
||||
При заводской прошивке в дефолтной конфигурации **отсутствуют** пулы и access-листы — их необходимо создавать вручную.
|
||||
|
||||
### 13.4.1. Переход в раздел, exit (..), root (/)
|
||||
|
||||
Навигация по дереву конфигурации выполняется следующим образом:
|
||||
|
||||
| Действие | Команда / клавиша | Пример |
|
||||
| ------------------------------- | ----------------- | -------------------------- |
|
||||
| Перейти в раздел | Имя раздела | `system` → переход в system |
|
||||
| Перейти на уровень выше | `..` или `exit` | Из mng-if → обратно в system |
|
||||
| Вернуться в корень конфигурации | `/` или `root` | Из любого уровня → в корень |
|
||||
|
||||
Пример навигации:
|
||||
|
||||
```text
|
||||
# system ← перешли в system
|
||||
# (system) mng-if ← перешли в management-интерфейс
|
||||
# (mng-if) .. ← вернулись в system
|
||||
# (system) serial ← перешли в serial
|
||||
# (serial) / ← вернулись в корень
|
||||
#
|
||||
```
|
||||
|
||||
На практике наиболее удобны **`..`** (на уровень выше) и **`/`** (в корень).
|
||||
|
||||
### 13.4.2. Автодополнение (Tab), история команд (↑↓), справка (?)
|
||||
|
||||
CLI поддерживает стандартный набор средств навигации:
|
||||
|
||||
| Клавиша / команда | Действие |
|
||||
| --------------------- | --------------------------------------------------------- |
|
||||
| **Tab** | Автодополнение команды (если единственный вариант) |
|
||||
| **↑ / ↓** | Переход по истории введённых команд |
|
||||
| **?** | Показать все доступные команды на текущем уровне |
|
||||
| **часть_команды + ?** | Показать команды, начинающиеся с введённого текста |
|
||||
| **!** | Показать доступные ветки конфигурации на текущем уровне |
|
||||
|
||||
## 13.5. Применение конфигурации: `apply`, сохранение: `wr`
|
||||
|
||||
Изменения в конфигурации **не применяются немедленно**. Процесс состоит из двух шагов:
|
||||
|
||||
```text
|
||||
Внесение изменений ──► apply ──► wr
|
||||
│ │ │
|
||||
│ │ └─ Сохранение в startup-config
|
||||
│ │ (переживёт перезагрузку)
|
||||
│ │
|
||||
│ └─ Применение к running-config
|
||||
│ (проверка синтаксиса, активация)
|
||||
│
|
||||
└─ Изменения только в буфере
|
||||
(не активны, не сохранены)
|
||||
```
|
||||
|
||||
| Команда | Действие |
|
||||
| --------- | --------------------------------------------------------------------------- |
|
||||
| **`apply`** | Проверяет синтаксическую корректность и применяет конфигурацию. Выдаёт сообщение об успехе или ошибке. Конфигурация становится активной, но **не сохраняется** при перезагрузке |
|
||||
| **`wr`** | Сохраняет текущую конфигурацию в **startup-config**. После перезагрузки устройство загрузится с сохранённой конфигурацией |
|
||||
|
||||
Если после `apply` не выполнить `wr` и перезагрузить устройство — оно вернётся к предыдущей сохранённой конфигурации.
|
||||
|
||||
## 13.6. Управление конфигурациями: save, load, copy, clear config
|
||||
|
||||
На фильтре существуют несколько предопределённых конфигураций:
|
||||
|
||||
| Конфигурация | Описание |
|
||||
| ------------------- | ----------------------------------------------------------- |
|
||||
| **Startup config** | Конфигурация, с которой устройство загружается |
|
||||
| **Effective config**| Текущая активная конфигурация (после последнего `apply`) |
|
||||
| **Factory config** | Заводская конфигурация по умолчанию (неизменяемая) |
|
||||
|
||||
Команды управления:
|
||||
|
||||
| Команда | Действие |
|
||||
| --------------------------- | ----------------------------------------------------------- |
|
||||
| `save <имя>` | Сохранить текущую конфигурацию на диск под указанным именем |
|
||||
| `load <имя>` | Загрузить ранее сохранённую конфигурацию |
|
||||
| `load effective` | Загрузить текущую активную конфигурацию (полезно, если кто-то изменил конфиг параллельно) |
|
||||
| `copy <URL>` | Скопировать конфигурацию на внешний сервер по URL |
|
||||
| `clear config` | Сбросить текущую конфигурацию до заводской |
|
||||
|
||||
> **Осторожно с `clear config`:** после выполнения `apply` management-адрес сменится на заводской. Если вы подключены по SSH — **потеряете доступ** к устройству. Останется только возможность подключения через физическую консоль.
|
||||
|
||||
## 13.7. Одновременная работа двух пользователей: ограничения
|
||||
|
||||
Одновременная настройка фильтра двумя пользователями **не рекомендуется**. Механизма совместного редактирования конфигурации на текущий момент не реализовано.
|
||||
|
||||
Проблема: последний, кто выполнит команду `apply`, **полностью перезаписывает** конфигурацию. Все изменения, внесённые другим пользователем и ранее применённые, будут **затёрты**.
|
||||
|
||||
Если вы обнаружили, что на устройстве работает кто-то ещё и вносит изменения, можно периодически выполнять команду `load effective` — это загрузит в ваш буфер текущую активную конфигурацию (с изменениями, внесёнными коллегой).
|
||||
|
||||
## 13.8. «Мышеловка» (trap mode) при незакрытой скобке
|
||||
|
||||
В CLI фильтра существует режим многострочного ввода для списков значений (DNS-серверы, IP-адреса и т.д.). Этот режим активируется, когда вы открываете **скобку**, но **не закрываете** её перед нажатием Enter.
|
||||
|
||||
В результате вы попадаете в особый режим (неофициально называемый **«мышеловкой»**), в котором:
|
||||
|
||||
- невозможно выйти командой `exit` или `..`;
|
||||
- невозможно перейти в корень конфигурации командой `/`;
|
||||
- никакие стандартные команды навигации не работают.
|
||||
|
||||
Способ выхода: **поставить закрывающую скобку**. После этого введённые данные применятся, и CLI вернётся на предыдущий уровень конфигурации.
|
||||
|
||||
Это **не баг, а особенность** (feature) — режим предназначен для построчного ввода списков значений. Если вы попали в него случайно, просто введите закрывающую скобку `)`.
|
||||
|
||||
## 13.9. Ключевое слово `ls` для быстрого просмотра
|
||||
|
||||
При переходе в любую ветку конфигурации можно добавить ключевое слово **`ls`** в конце команды. Это приведёт к тому, что вы не просто перейдёте в указанный раздел, а сразу **увидите его содержимое** на экране.
|
||||
|
||||
```text
|
||||
# system ls ← перейти в system и сразу показать всё содержимое
|
||||
# system mng-if ls ← перейти в mng-if и сразу показать настройки
|
||||
```
|
||||
|
||||
Это удобное сокращение, экономящее время при просмотре конфигурации — вместо двух действий (переход + просмотр) выполняется одно.
|
||||
|
||||
Аналогично, при вводе описаний (description) для интерфейсов и других сущностей значения вводятся **в кавычках**, если они содержат спецсимволы (например, дефис `-` может быть воспринят как оператор, а не как часть строки).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 12: Сессии и трансляции на фильтре](12.md) · [Раздел 14: Фильтр: конфигурация подсистем →](14.md)
|
||||
232
14.md
Normal file
232
14.md
Normal file
@@ -0,0 +1,232 @@
|
||||
# 14. Фильтр: конфигурация подсистем
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md)
|
||||
|
||||
---
|
||||
|
||||
## 14.1. Консольный порт: скорость, тайм-аут неактивности
|
||||
|
||||
В секции настройки консольного порта (`system / serial`) доступны два параметра:
|
||||
|
||||
| Параметр | Описание | Рекомендация |
|
||||
| ---------------------- | ----------------------------------------------- | --------------------------- |
|
||||
| **Скорость порта** | Скорость консольного соединения (по умолчанию 115200) | Не менять |
|
||||
| **Тайм-аут неактивности** | Время до автоматического отключения неактивного пользователя | 5–30 минут (не `never`) |
|
||||
|
||||
По умолчанию тайм-аут неактивности составляет **5 минут**. Можно увеличить до 15 или 30 минут. Значение `never` **не рекомендуется** — при его установке пользователь не будет отключаться по тайм-ауту, что может привести к проблемам (аналогично проблеме SSH-сессий — см. [раздел 14.3.1](#1431-лимит-сессий-20-опасность-never-для-auto-logout)).
|
||||
|
||||
## 14.2. Management-интерфейс: IP, gateway, DNS, allowed IP
|
||||
|
||||
В секции management-интерфейса (`system / mng-if`) настраиваются параметры удалённого доступа к фильтру:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------- | ----------------------------------------------------------------- |
|
||||
| **IP-адрес** | Адрес management-интерфейса в подсети управления |
|
||||
| **Gateway** | Шлюз по умолчанию (обычно .254 — криптошлюз «Континент») |
|
||||
| **Name servers**| Список DNS-серверов (можно указать несколько через пробел) |
|
||||
| **Allowed IP** | Список адресов/подсетей, которым разрешён удалённый доступ |
|
||||
|
||||
> **Осторожно:** изменение IP-адреса или allowed IP с последующим `apply` может привести к **потере удалённого доступа** к устройству, если вы подключены по SSH. Единственным способом восстановления в таком случае будет подключение через физическую консоль.
|
||||
|
||||
### 14.2.1. Добавление/удаление записей: `+=` и `-=`
|
||||
|
||||
Для параметров, принимающих списки значений (DNS-серверы, allowed IP и др.), доступны операторы поэлементного изменения:
|
||||
|
||||
| Оператор | Действие | Пример |
|
||||
| -------- | --------------------------------- | ----------------------------------- |
|
||||
| `+=` | Добавить запись к существующему списку | `nameservers += 8.8.8.8` |
|
||||
| `-=` | Удалить запись из списка | `nameservers -= 8.8.8.8` |
|
||||
|
||||
Альтернативный способ — задать весь список одной строчкой через пробел:
|
||||
|
||||
```text
|
||||
nameservers 192.168.1.45 8.8.8.8 8.8.4.4
|
||||
```
|
||||
|
||||
Также можно использовать режим многострочного ввода через скобки (см. [раздел 13.8 — «мышеловка»](13.md)).
|
||||
|
||||
## 14.3. Терминал (SSH): auto-logout, prompt, нумерация строк
|
||||
|
||||
В секции терминала (`system / terminal`) настраиваются параметры SSH-доступа:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------- | ------------------------------------------------------ |
|
||||
| **auto-logout** | Время автоматического отключения неактивной SSH-сессии |
|
||||
| **prompt** | Текст приглашения командной строки |
|
||||
| **Нумерация строк** | Отображение номера введённой команды (инкрементируется с каждым вводом) |
|
||||
|
||||
При вводе значения prompt необходимо использовать **кавычки**, если значение содержит спецсимволы (дефис `-` и др.).
|
||||
|
||||
### 14.3.1. Лимит сессий (20), опасность `never` для auto-logout
|
||||
|
||||
Значение `never` для auto-logout **категорически не рекомендуется**. Причина:
|
||||
|
||||
1. При нестабильном соединении SSH-сессии **обрываются**, но не закрываются на стороне фильтра;
|
||||
2. «Мёртвые» сессии **накапливаются**, не удаляясь по тайм-ауту;
|
||||
3. При достижении лимита в **20 сессий** вы **не сможете** подключиться к устройству по SSH;
|
||||
4. Единственный способ восстановления — подключение через физическую консоль.
|
||||
|
||||
Рекомендуется оставлять auto-logout со значением по умолчанию или устанавливать разумный тайм-аут.
|
||||
|
||||
## 14.4. Пользователи: создание, удаление, уровни доступа, пароли (secret 0 / 15)
|
||||
|
||||
Управление пользователями осуществляется в секции `system / users`:
|
||||
|
||||
| Команда | Действие |
|
||||
| ------------------------------------------ | --------------------------- |
|
||||
| `create user <имя> level <N> secret 0 <пароль>` | Создать пользователя (пароль в открытом виде) |
|
||||
| `create user <имя> level <N> secret 15 <хэш>` | Создать пользователя (пароль в виде хэша) |
|
||||
| `no user <имя>` | Удалить пользователя |
|
||||
|
||||
Параметры пароля:
|
||||
|
||||
| Формат | Описание |
|
||||
| ------------ | ----------------------------------------------------- |
|
||||
| **secret 0** | Пароль задаётся в открытом виде (plain text) |
|
||||
| **secret 15**| Ожидается хэш пароля |
|
||||
|
||||
В конфигурации пароли **хранятся в хэшированном виде** — при просмотре конфигурации открытые пароли не отображаются.
|
||||
|
||||
Пользователь по умолчанию (`admin` / `econat`) может быть удалён. Рекомендуется создать новых пользователей и удалить дефолтного.
|
||||
|
||||
## 14.5. TACACS+: авторизация, fallback на локальную базу
|
||||
|
||||
Фильтр поддерживает внешнюю авторизацию через **TACACS+**. Через TACACS+ работает только **авторизация** (и, возможно, аккаунтинг).
|
||||
|
||||
Ключевые параметры:
|
||||
|
||||
| Параметр | Описание | Важность |
|
||||
| --------------------- | -------------------------------------------------------------- | -------- |
|
||||
| **Fallback (fb on)** | При недоступности TACACS+ авторизовать через локальную базу | **Критично** |
|
||||
| **Service type** | Тип сервиса (shell) — должен совпадать с настройкой на TACACS-сервере | Важно |
|
||||
| **Protocol** | Протокол — должен совпадать с настройкой на TACACS-сервере | Важно |
|
||||
| **Серверы** | IP-адрес/доменное имя + secret для каждого сервера TACACS+ | — |
|
||||
|
||||
> **Важно:** параметр **`fb on`** (fallback) должен быть **включён**. Если он выключен и пользователь отсутствует на TACACS-сервере (или сервер недоступен), авторизация через CLI будет **невозможна**.
|
||||
|
||||
## 14.6. NTP: до 3 серверов, период обновления
|
||||
|
||||
В секции NTP (`system / ntp`) настраивается синхронизация времени:
|
||||
|
||||
- Можно указать до **3 NTP-серверов**;
|
||||
- Настраивается **период обновления** времени.
|
||||
|
||||
Для проверки статуса синхронизации используется команда `show ntp`. Вывод команды может быть не вполне интуитивным — значение `0x24` в статусе указывает на успешную синхронизацию.
|
||||
|
||||
> **Примечание:** в будущих прошивках логика работы со временем планируется к изменению. Вместо задания временного сдвига в отдельных подсистемах будет единая настройка временной зоны для всего устройства, а в подсистемах — выбор между UTC и локальным временем.
|
||||
|
||||
## 14.7. SNMP: community (read-only), traps, allow-ip
|
||||
|
||||
Настройки SNMP (`system / snmp`) стандартны:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------- | ----------------------------------------------------------- |
|
||||
| **Community** | Строка community, работает **только на чтение** (read-only). Задавать параметры через SNMP нельзя |
|
||||
| **Traps** | Включение/выключение отправки SNMP-трапов |
|
||||
| **Allow IP** | Список адресов/подсетей, которым разрешён SNMP-доступ (по умолчанию — отовсюду) |
|
||||
| **Description** | Описание устройства |
|
||||
| **Hostname** | Имя устройства |
|
||||
| **Contact** | Контактная информация |
|
||||
|
||||
## 14.8. Системное журналирование (syslog)
|
||||
|
||||
Системное журналирование настраивается в секции `system / syslog` и позволяет отправлять события с фильтра на внешние серверы (СПХД).
|
||||
|
||||
### 14.8.1. Внешние лог-серверы (до 2), hostname, time shift
|
||||
|
||||
| Параметр | Описание |
|
||||
| ----------------- | ------------------------------------------------------------ |
|
||||
| **Enable/disable**| Включение/выключение системного логирования |
|
||||
| **Серверы** | До **2 внешних серверов** (IP-адрес + порт) |
|
||||
| **Hostname** | Имя устройства, которое будет отображаться в syslog-сообщениях на внешнем сервере |
|
||||
| **Time shift** | Временной сдвиг относительно UTC (в минутах) для логов |
|
||||
|
||||
В рамках **пилотного проекта** (Урал) системные логи на внешний сервер не сохранялись. В **федеральном проекте** они должны сохраняться на **СПХД** (серверы предварительного хранения данных), обеспечивая ретроспективный анализ событий на всех устройствах площадки — это крайне полезная возможность, которой часто не хватало на пилоте.
|
||||
|
||||
> **Примечание:** в будущих прошивках параметр time shift планируется заменить на выбор между UTC и локальным временем, а временная зона будет настраиваться единообразно для всего устройства.
|
||||
|
||||
### 14.8.2. Уровни логирования по подсистемам (1=ошибки, 2=предупреждения, 3=информация)
|
||||
|
||||
Для каждой подсистемы фильтра можно индивидуально настроить **уровень подробности** журналирования:
|
||||
|
||||
| Уровень | Название | Содержимое | Рекомендация |
|
||||
| ------- | -------------- | --------------------------------------------------- | ------------------------- |
|
||||
| **1** | Ошибки | Ошибки и критически важные сообщения | По умолчанию, достаточно для большинства случаев |
|
||||
| **2** | Предупреждения | Предупреждения + всё из уровня 1 | Включать при траблшутинге |
|
||||
| **3** | Информация | Информационные сообщения + всё из уровней 1–2 | Только при диагностике |
|
||||
|
||||
По умолчанию для всех подсистем установлен **уровень 1**. Повышать уровень (2 или 3) рекомендуется **только на время диагностики**, поскольку:
|
||||
|
||||
- объём логов при уровне 2–3 **очень большой**;
|
||||
- внутренние логи на устройстве **забиваются быстро**;
|
||||
- разбираться в детальных логах **сложно**.
|
||||
|
||||
Не все подсистемы, указанные в конфигурации, реально существуют в прошивке проекта ТСПУ (например, BRAS отсутствует) — для несуществующих подсистем настройка не имеет эффекта.
|
||||
|
||||
### 14.8.3. Подсистема `all` — максимальный уровень для всех
|
||||
|
||||
Условная подсистема **`all`** позволяет быстро установить уровень логирования для **всех** подсистем одновременно:
|
||||
|
||||
```text
|
||||
verbose all 3 ← установить максимальный уровень для всех подсистем
|
||||
```
|
||||
|
||||
Правило выбора уровня: для каждой подсистемы выбирается **наибольший** из двух значений — установленного для `all` и установленного индивидуально. Например, если `all = 2` и для конкретной подсистемы задано `3`, будет использоваться `3`.
|
||||
|
||||
### 14.8.4. Логирование команд пользователя (уровень fatal)
|
||||
|
||||
Все команды, введённые пользователем, логируются с уровнем **fatal**. Это не означает, что происходит что-то критическое — уровень fatal выбран специально, чтобы команды пользователя **всегда записывались** в логи, независимо от текущих настроек подробности.
|
||||
|
||||
Это полезно для ретроспективного анализа: можно посмотреть, кто, когда и что настраивал на устройстве.
|
||||
|
||||
### 14.8.5. SNMP traps: только уровень fatal
|
||||
|
||||
В SNMP отправляются трапы **только уровня fatal**. События уровней 1–3 (ошибки, предупреждения, информация) в SNMP-трапы **не попадают**.
|
||||
|
||||
## 14.9. Журналирование соединений (connection log) — через лог-интерфейс (DPDK)
|
||||
|
||||
Журналирование соединений (connection log, в терминологии фильтра — «NAT translation log») позволяет логировать каждую создаваемую на устройстве сессию: какой абонент, на какой ресурс, по какому порту обращался.
|
||||
|
||||
Ключевые особенности:
|
||||
|
||||
- Логи отправляются на внешний сервер в специальном формате;
|
||||
- В отличие от syslog, connection log по умолчанию отправляется через **лог-интерфейс** (DPDK), а не через management-интерфейс;
|
||||
- Лог-интерфейс **не имеет IP-адреса** в традиционном смысле — адрес генерируется программно. Пропинговать лог-интерфейс извне **невозможно**: на нём нет сущности, обрабатывающей входящие пакеты. Это сделано для **повышения производительности** — интерфейс отдан под управление DPDK;
|
||||
- Формат логирования настраивается в соответствующей секции конфигурации.
|
||||
|
||||
> **Примечание:** в проекте ТСПУ журналирование соединений в текущей конфигурации может не использоваться.
|
||||
|
||||
## 14.10. Журналирование протоколов (debug logger) — отправка на SPFS
|
||||
|
||||
Секция **debug logger** (несмотря на название «debug», это штатная функциональность) отвечает за отправку **протокольных логов** — результатов распознавания протоколов движком DPI — на серверы **SPFS** для дальнейшего формирования очищенных списков блокировки (подробнее о полном цикле — в [разделе 8](08.md)).
|
||||
|
||||
### 14.10.1. Выбор протоколов (all / конкретные)
|
||||
|
||||
| Параметр | Описание |
|
||||
| ----------------- | ----------------------------------------------------------- |
|
||||
| **Enable** | Включение секции debug logger |
|
||||
| **Protocols** | Список протоколов для логирования: `all` (все) или конкретные (Telegram, WhatsApp и др.) |
|
||||
| **Server + port** | Адрес и порт SPFS-сервера |
|
||||
| **Gateway** | Шлюз по умолчанию для отправки |
|
||||
| **Source port** | Порт источника, с которого отправляются логи |
|
||||
| **Log interface** | Интерфейс для отправки: `log` (по умолчанию) или `management` |
|
||||
|
||||
По умолчанию протоколы установлены в **`all`** — логируются все распознаваемые протоколы. Можно указать только конкретные протоколы, если требуется сузить объём логирования.
|
||||
|
||||
Лог-интерфейс для отправки по умолчанию — **log** (DPDK). Переключение на management **не рекомендуется**, так как производительность отправки значительно снизится.
|
||||
|
||||
### 14.10.2. Количество пакетов на протокол (по умолчанию 30, рекомендуется 3)
|
||||
|
||||
Параметр **количества пакетов** определяет, сколько пакетов из каждой распознанной сессии отправляется в лог:
|
||||
|
||||
| Значение | Описание | Рекомендация |
|
||||
| ------------- | ------------------------------------------------- | ------------------- |
|
||||
| **0** | Без ограничения (отправляются первые 30 пакетов) | По умолчанию |
|
||||
| **3** | Отправляются первые 3 пакета | **Рекомендуется** |
|
||||
| **30** | Максимальное количество | Избыточно |
|
||||
|
||||
Значение **30** (фактически — значение по умолчанию при параметре 0) генерирует **избыточный объём** лог-трафика. По результатам тестирования на Урале, для корректного распознавания достаточно **3 пакетов** — это значение рекомендуется для production-эксплуатации.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 13: Фильтр: первоначальная настройка и CLI](13.md) · [Раздел 15: Фильтр: настройка интерфейсов и общих параметров →](15.md)
|
||||
123
15.md
Normal file
123
15.md
Normal file
@@ -0,0 +1,123 @@
|
||||
# 15. Фильтр: настройка интерфейсов и общих параметров
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md)
|
||||
|
||||
---
|
||||
|
||||
## 15.1. Интерфейсы: enable/disable, description (LACP не используется)
|
||||
|
||||
Фильтр обрабатывает трафик на **уровне L2** — для внешнего наблюдателя устройство представляет собой «прозрачный провод». На пути прохождения трафика **нет L3-интерфейсов**. Если посмотреть на интерфейсы в операционной системе Linux (на которой основано устройство), виден **только management-интерфейс** — все остальные интерфейсы отданы под управление **DPDK** и обрабатываются специализированным программным обеспечением.
|
||||
|
||||
Настройки интерфейсов для пропуска трафика **минимальны**:
|
||||
|
||||
| Действие | Команда |
|
||||
| ------------------ | ------------------------------ |
|
||||
| Включить интерфейс | `enable` |
|
||||
| Выключить интерфейс| `disable` |
|
||||
| Задать описание | `description "текст"` |
|
||||
|
||||
Лог-интерфейсы **жёстко привязаны** к конкретным физическим портам и не могут быть переназначены.
|
||||
|
||||
В конфигурации могут присутствовать настройки протокола **LACP** — в проекте ТСПУ он **не используется**. Эти параметры существуют по умолчанию, их не нужно изменять или удалять.
|
||||
|
||||
## 15.2. NAT Defaults — общие параметры устройства
|
||||
|
||||
Секция `nat-defaults` содержит общие параметры, влияющие на работу всего устройства. Название секции — наследие от CGNAT-платформы, однако параметры применяются ко всему функционалу фильтра, включая DPI.
|
||||
|
||||
### 15.2.1. VLAN Mode: untag / vlan / QinQ — глубина поиска IP-заголовка (всегда QinQ)
|
||||
|
||||
Параметр **VLAN Mode** определяет, насколько глубоко фильтр ищет IP-заголовок внутри Ethernet-фрейма:
|
||||
|
||||
| Значение | Поведение | Применение в ТСПУ |
|
||||
| ------------ | ----------------------------------------------------------------- | ------------------ |
|
||||
| **untag** | IP-заголовок ищется только в нетегированных фреймах. Пакеты с VLAN-тегами пропускаются прозрачно | Нет |
|
||||
| **vlan** | IP-заголовок ищется в пакетах без тегов и с одним VLAN-тегом | Нет |
|
||||
| **QinQ** | IP-заголовок ищется при любом количестве VLAN-тегов: 0, 1 или 2 | **Всегда** |
|
||||
|
||||
В проекте ТСПУ параметр **всегда должен быть установлен в `QinQ`**. При любом другом значении часть трафика (с VLAN-тегами) будет **прозрачно пропускаться** без обработки, что недопустимо.
|
||||
|
||||
### 15.2.2. Sessions per Translation (по умолчанию 4096)
|
||||
|
||||
Параметр задаёт **максимальное количество сессий** в рамках одной трансляции. Значение по умолчанию — **4096**. В проекте ТСПУ менять его не требуется — этого значения достаточно для всех сценариев.
|
||||
|
||||
### 15.2.3. Forward Traffic: всегда ON
|
||||
|
||||
Параметр **Forward Traffic** управляет пересылкой трафика через устройство:
|
||||
|
||||
| Значение | Поведение |
|
||||
| -------- | ------------------------------------------------------------ |
|
||||
| **on** | Трафик проходит через фильтр и отправляется дальше |
|
||||
| **off** | Трафик принимается, но не отправляется (режим зеркала) |
|
||||
|
||||
В проекте ТСПУ параметр **всегда должен быть `on`** (значение по умолчанию). Режим `off` используется только при работе с зеркалированным трафиком, что в данном проекте не применяется.
|
||||
|
||||
### 15.2.4. L2 MTU: максимум 9216 (по RFC)
|
||||
|
||||
Параметр **L2 MTU** определяет максимальный размер кадра на уровне L2. По умолчанию установлено значение **1522**.
|
||||
|
||||
В проекте ТСПУ рекомендуется устанавливать **максимально возможное значение — 9216** (максимум по RFC). Это позволяет полностью исключить проблемы с MTU:
|
||||
|
||||
```text
|
||||
nat-defaults
|
||||
l2-mtu 9216
|
||||
```
|
||||
|
||||
На балансировщиках MTU на интерфейсах также выставляется в районе **9000**, что позволяет закрыть проблему MTU на всей цепочке оборудования ТСПУ.
|
||||
|
||||
### 15.2.5. LLDP: выключен (требование операторов — прозрачность)
|
||||
|
||||
Протокол **LLDP** (Link Layer Discovery Protocol) на фильтрах **должен быть выключен**. Это сделано по требованию операторов связи, которые не хотят видеть оборудование ТСПУ в своей сети.
|
||||
|
||||
Принцип прозрачности: оператор ожидает, что ТСПУ — это «невидимый провод». Если LLDP включён, устройство начинает анонсировать себя в сети оператора, что нарушает эту прозрачность. Например, МТС потребовал отключить LLDP, поскольку устройства ТСПУ появлялись на их схемах сети.
|
||||
|
||||
### 15.2.6. Permit Invalid Flow: всегда ON — приём TCP-сессий без SYN
|
||||
|
||||
Параметр **Permit Invalid Flow** — один из **наиболее критичных** параметров конфигурации. Он **всегда должен быть включён** в проекте ТСПУ.
|
||||
|
||||
**Что он делает:**
|
||||
|
||||
| Значение | Поведение |
|
||||
| -------- | --------------------------------------------------------------- |
|
||||
| **off** | TCP-сессия заводится **только** по TCP SYN-пакету. Пакеты без SYN-флага дропаются |
|
||||
| **on** | TCP-сессия заводится по **любому** TCP-пакету, включая пакеты без SYN |
|
||||
|
||||
**Почему `off` опасен в контексте ТСПУ:**
|
||||
|
||||
1. **Переключение режимов.** При переключении ТСПУ из режима байпаса обратно в рабочий режим (inline) на фильтры мгновенно поступает большой объём трафика — уже установленных TCP-сессий. SYN-пакеты для этих сессий давно прошли. Если `permit invalid flow` выключен, фильтр **дропнет** весь этот трафик. Для абонентов это означает, что **все их TCP-сессии** отвалятся по тайм-ауту и потребуют переустановки;
|
||||
|
||||
2. **Асимметричный трафик.** Если исходящий трафик уходит через один фильтр, а входящий приходит через другой — на одном из фильтров сессия не будет установлена (нет SYN-флага), и трафик будет дропаться.
|
||||
|
||||
С этой проблемой сталкивались **неоднократно** на практике.
|
||||
|
||||
## 15.3. Тайм-ауты сессий и трансляций
|
||||
|
||||
В секции `nat-defaults` также настраиваются **тайм-ауты** для сессий и трансляций (подробнее о сессиях и трансляциях — в [разделе 12](12.md)):
|
||||
|
||||
- Тайм-ауты для **трансляций** и **сессий** задаются **раздельно**;
|
||||
- Параметры различаются по типу протокола (TCP, UDP, ICMP);
|
||||
- Значения в `nat-defaults` являются **значениями по умолчанию**, которые наследуются каждым создаваемым пулом;
|
||||
- При необходимости тайм-ауты могут быть **переопределены** на уровне конкретного пула.
|
||||
|
||||
В секции также присутствует параметр **limiter** — ограничения на количество выделяемых портов для одного пользователя. Этот параметр актуален **только для NAT** и в проекте ТСПУ **не используется**.
|
||||
|
||||
## 15.4. IPv6: включение, диапазон адресов для обработки
|
||||
|
||||
Поддержка IPv6 была добавлена в прошивку позднее основного функционала. Настройка расположена в отдельном разделе:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------- | ------------------------------------------------------------ |
|
||||
| **Enable/disable** | Включение или выключение обработки IPv6-трафика |
|
||||
| **Тайм-ауты** | Отдельные тайм-ауты для IPv6-сессий (по умолчанию можно не менять) |
|
||||
| **Диапазон адресов** | Список IPv6-адресов и VLAN, которые будут обрабатываться |
|
||||
|
||||
В проекте ТСПУ IPv6 должен быть **включён**. По умолчанию в диапазон обработки включены **все IPv6-адреса во всех VLAN** — менять это значение, как правило, не требуется.
|
||||
|
||||
При необходимости можно:
|
||||
|
||||
- **Включить** в обработку только конкретные диапазоны IPv6-адресов;
|
||||
- **Исключить** определённые диапазоны из обработки;
|
||||
- Полностью **отключить** обработку IPv6-трафика (тогда DPI-фильтрация по IPv6 выполняться не будет, трафик пройдёт прозрачно).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 14: Фильтр: конфигурация подсистем](14.md) · [Раздел 16: Фильтр: ACL и пулы →](16.md)
|
||||
198
16.md
Normal file
198
16.md
Normal file
@@ -0,0 +1,198 @@
|
||||
# 16. Фильтр: ACL и пулы — запуск трафика на обработку
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md)
|
||||
|
||||
---
|
||||
|
||||
Чтобы фильтр начал обрабатывать трафик, необходимо выполнить два действия: **создать пул** и **привязать к нему ACL**. Без этих настроек — какие бы DPI-листы ни были сконфигурированы — весь трафик будет прозрачно пропускаться через устройство без какой-либо обработки.
|
||||
|
||||
Это одна из ключевых стадий в пути прохождения пакета через фильтр (подробнее — в [разделе 5.1](05.md)): IP-пакет должен попасть в ACL и в пул, чтобы далее передаваться на обработку движком DPI.
|
||||
|
||||
> **Важно:** при заводской (дефолтной) конфигурации фильтра пулы и ACL **отсутствуют**. Их необходимо создать вручную при первоначальной настройке.
|
||||
|
||||
## 16.1. Создание ACL: `create acl`, правила (allow/deny), протоколы, source/destination, VLAN
|
||||
|
||||
ACL (Access Control List) — это набор правил, определяющих, какой трафик подлежит обработке. Изначально на фильтре нет ни одного ACL — его нужно создать.
|
||||
|
||||
### Создание и переход в ACL
|
||||
|
||||
| Действие | Команда | Пример |
|
||||
| ---------------------- | ------------------------------ | ------------------------- |
|
||||
| Создать ACL | `create acl <имя>` | `create acl aclfake` |
|
||||
| Перейти в ACL | `go to acl<имя>` | `go to aclaclfake` |
|
||||
| Удалить ACL | `no acl <имя>` | `no acl aclfake` |
|
||||
|
||||
> **Обратите внимание:** команда перехода `go to acl<имя>` пишется **слитно** — `aclaclfake`, а не `acl aclfake`. Здесь `acl` — это часть пути, а `aclfake` — название списка.
|
||||
|
||||
### Создание правил
|
||||
|
||||
Внутри ACL создаются правила, каждое из которых определяет, какой трафик разрешить (`allow`) или запретить (`deny`) для обработки:
|
||||
|
||||
```text
|
||||
<номер> allow|deny <протокол> <source> <destination> [vlan <N>|<N-M>]
|
||||
```
|
||||
|
||||
Структура правила:
|
||||
|
||||
| Элемент | Описание | Примеры |
|
||||
| ---------------- | ---------------------------------------------------------------- | ------------------------------ |
|
||||
| **Номер** | Порядковый номер правила (рекомендуется с зазором: 10, 20, 30) | `10`, `20`, `30` |
|
||||
| **Действие** | `allow` (или `permit`) / `deny` — разрешить или запретить | `allow`, `deny` |
|
||||
| **Протокол** | IP, TCP, UDP, ICMP и др. | `ip`, `tcp`, `udp` |
|
||||
| **Source** | Источник: хост, подсеть или `any` (любой) | `any`, `10.0.0.0/8`, `host 1.2.3.4` |
|
||||
| **Destination** | Назначение: хост, подсеть или `any` | `any`, `192.168.0.0/16` |
|
||||
| **VLAN** | Номер или диапазон VLAN (необязательно) | `vlan 100`, `vlan 100-200` |
|
||||
|
||||
Ключевые слова `allow` и `permit` — **синонимы**, можно использовать любое из них.
|
||||
|
||||
### Поведение VLAN по умолчанию
|
||||
|
||||
Если номер VLAN **не указан**, правило автоматически применяется ко **всем VLAN** (0–4095). Это поведение по умолчанию подходит для большинства сценариев в проекте ТСПУ.
|
||||
|
||||
При необходимости можно указать:
|
||||
|
||||
- конкретный VLAN: `vlan 100`
|
||||
- диапазон VLAN: `vlan 100-200`
|
||||
|
||||
### Управление правилами
|
||||
|
||||
| Действие | Команда |
|
||||
| --------------------- | ------------------------ |
|
||||
| Удалить правило | `no <номер>` |
|
||||
| Просмотреть ACL | `ls` (в контексте ACL) |
|
||||
|
||||
Номера правил рекомендуется задавать **с зазором** (10, 20, 30...) — это позволяет вставлять новые правила между существующими без перенумерации.
|
||||
|
||||
### Типовой ACL для проекта ТСПУ
|
||||
|
||||
В проекте ТСПУ, как правило, используется простейший ACL, пропускающий весь IP-трафик на обработку:
|
||||
|
||||
```text
|
||||
create acl aclfake
|
||||
go to aclaclfake
|
||||
10 allow ip any any
|
||||
apply
|
||||
```
|
||||
|
||||
Правила обрабатываются **по порядку номеров** — первое совпавшее правило определяет судьбу пакета. Это аналогично работе ACL на маршрутизаторах: если пакет совпал с правилом `allow`, он направляется в пул; если с правилом `deny` — прозрачно пропускается мимо пула.
|
||||
|
||||
## 16.2. Создание пула: `create pool`, тип = fake (без NAT)
|
||||
|
||||
Пул — логическая сущность, в которую попадает трафик, отобранный ACL, для дальнейшей обработки. В проекте ТСПУ тип пула **всегда** должен быть **fake**.
|
||||
|
||||
### Создание пула
|
||||
|
||||
```text
|
||||
create pool poolfake
|
||||
go to poolpoolfake
|
||||
```
|
||||
|
||||
### Тип пула: fake
|
||||
|
||||
| Тип пула | Описание | Применение в ТСПУ |
|
||||
| ---------- | ----------------------------------------------------------- | ------------------ |
|
||||
| **fake** | «Фейковый» пул — трансляция адресов не выполняется: что пришло, то и ушло | **Всегда** |
|
||||
| Другие типы | Реальная трансляция адресов (NAT) | Не используется |
|
||||
|
||||
Тип `fake` означает, что фильтр **не изменяет** IP-адреса в проходящих пакетах. Это наследие CGNAT-платформы: механизм пулов изначально создавался для трансляции адресов, но в проекте ТСПУ трансляция не нужна. Тем не менее пул **должен быть создан** — без него трафик не попадёт на обработку DPI.
|
||||
|
||||
### Минимальные настройки пула
|
||||
|
||||
| Параметр | Значение | Описание |
|
||||
| ----------- | ------------- | --------------------------------------- |
|
||||
| **type** | `fake` | Тип пула — без трансляции адресов |
|
||||
| **enable** | Включён | Пул должен быть активен |
|
||||
| **acl** | `<имя ACL>` | Привязка ACL к пулу |
|
||||
|
||||
Этих трёх настроек **достаточно** для запуска трафика на обработку.
|
||||
|
||||
## 16.3. Привязка ACL к пулу
|
||||
|
||||
Привязка ACL к пулу выполняется командой `acl` внутри контекста пула:
|
||||
|
||||
```text
|
||||
go to poolpoolfake
|
||||
acl aclfake
|
||||
type fake
|
||||
enable
|
||||
apply
|
||||
```
|
||||
|
||||
Именно привязка ACL к пулу определяет, **какой именно трафик** будет попадать на обработку DPI. Без привязанного ACL пул не будет отбирать трафик, и обработка не начнётся.
|
||||
|
||||
Полная последовательность создания минимальной рабочей конфигурации:
|
||||
|
||||
```text
|
||||
# 1. Создаём ACL
|
||||
create acl aclfake
|
||||
go to aclaclfake
|
||||
10 allow ip any any
|
||||
exit
|
||||
|
||||
# 2. Создаём пул и привязываем ACL
|
||||
create pool poolfake
|
||||
go to poolpoolfake
|
||||
type fake
|
||||
acl aclfake
|
||||
enable
|
||||
exit
|
||||
|
||||
# 3. Применяем и сохраняем
|
||||
apply
|
||||
wr
|
||||
```
|
||||
|
||||
## 16.4. Приоритет пулов
|
||||
|
||||
При наличии нескольких пулов на фильтре трафик может совпасть с ACL **разных пулов**. В этом случае пакет попадёт в пул с **наивысшим приоритетом**.
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------- | ----------------------------------------------------------- |
|
||||
| **priority** | Числовое значение приоритета пула (чем выше — тем приоритетнее) |
|
||||
|
||||
На практике в проекте ТСПУ обычно используется **один пул**, поэтому настройка приоритета, как правило, не требуется. Однако при необходимости разделения трафика на разные пулы (например, для разных DPI-листов или разных политик обработки) приоритеты позволяют контролировать порядок отбора.
|
||||
|
||||
## 16.5. Connection logging в пуле
|
||||
|
||||
Параметр **connection log** в пуле управляет журналированием соединений (NAT translation log) — записью информации о каждой создаваемой сессии: какой абонент, на какой ресурс, по какому порту обращался.
|
||||
|
||||
| Значение | Описание |
|
||||
| -------- | ------------------------------------------------------- |
|
||||
| **on** | Журналирование соединений для данного пула включено |
|
||||
| **off** | Журналирование отключено |
|
||||
|
||||
По умолчанию connection logging **включён**. В проекте ТСПУ этот параметр может быть как задействован, так и не использоваться — зависит от конкретной площадки и требований DevOps-команды.
|
||||
|
||||
Помимо connection log, в пуле присутствуют:
|
||||
|
||||
- **Тайм-ауты** — наследуются из секции `nat-defaults` при создании пула (подробнее — в [разделе 15.3](15.md)). При необходимости могут быть переопределены на уровне пула;
|
||||
- **Ограничения на пользователей (limiter)** — актуальны только для NAT, в проекте ТСПУ **не используются**;
|
||||
- **Параметр PIN** — по умолчанию включён, актуален для режима с трансляцией адресов. В проекте ТСПУ менять не требуется.
|
||||
|
||||
## 16.6. IPv6 в пуле
|
||||
|
||||
Поддержка IPv6 в пуле настраивается аналогично глобальным настройкам IPv6 (подробнее — в [разделе 15.4](15.md)):
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------- | ------------------------------------------------------------ |
|
||||
| **Enable/disable** | Включение или выключение обработки IPv6-трафика в данном пуле |
|
||||
| **Тайм-ауты** | Отдельные тайм-ауты для IPv6-сессий (можно не менять) |
|
||||
| **Диапазон адресов** | Список IPv6-адресов и VLAN для обработки |
|
||||
|
||||
В проекте ТСПУ IPv6 в пуле должен быть **включён**. По умолчанию в диапазон обработки включены **все IPv6-адреса во всех VLAN** — менять это значение, как правило, не требуется.
|
||||
|
||||
При необходимости можно:
|
||||
|
||||
- включить в обработку только конкретные диапазоны IPv6-адресов;
|
||||
- исключить определённые диапазоны из обработки;
|
||||
- полностью отключить обработку IPv6-трафика в рамках данного пула.
|
||||
|
||||
---
|
||||
|
||||
### Диагностическая заметка: `show cps` показывает ноль
|
||||
|
||||
Если команда `show cps` показывает нулевое количество создаваемых сессий, одна из возможных причин — трафик **не попадает в пул**. Это может означать, что ACL не отбирает трафик: через фильтр могут идти гигабиты и десятки гигабит, но если пакеты не совпадают с правилами ACL привязанного пула, сессии создаваться не будут (подробнее — в [разделе 18.9](18.md)).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 15: Фильтр: настройка интерфейсов и общих параметров](15.md) · [Раздел 17: Фильтр: настройка DPI →](17.md)
|
||||
310
17.md
Normal file
310
17.md
Normal file
@@ -0,0 +1,310 @@
|
||||
# 17. Фильтр: настройка DPI
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md)
|
||||
|
||||
---
|
||||
|
||||
Модуль DPI (Deep Packet Inspection) — ключевая подсистема фильтра, отвечающая за анализ и фильтрацию трафика. Настройки DPI включают общие параметры модуля, конфигурацию работы с реестром Роскомнадзора, параметры деградации протоколов и индивидуальные настройки DPI-листов.
|
||||
|
||||
> **Примечание:** формат секции DPI различается между пилотным проектом (Урал) и федеральным проектом. В пилотном проекте настройки реестра Роскомнадзора находятся внутри DPI-листа 0. В федеральном проекте они вынесены в отдельную секцию, а все DPI-листы (0–15) стали абсолютно идентичными по структуре.
|
||||
|
||||
## 17.1. Общие настройки модуля DPI
|
||||
|
||||
Общие настройки расположены в корне секции `dpi` конфигурации фильтра.
|
||||
|
||||
### 17.1.1. Включение/выключение DPI
|
||||
|
||||
| Значение | Поведение |
|
||||
| ----------- | --------------------------------------------------------- |
|
||||
| **enable** | Модуль DPI активен, трафик анализируется и обрабатывается |
|
||||
| **disable** | Модуль DPI выключен, весь трафик пропускается прозрачно |
|
||||
|
||||
В рабочем режиме DPI должен быть **включён**. Выключение модуля DPI может использоваться для **диагностики**: если выключить DPI и убедиться, что фильтр больше не влияет на трафик — значит, проблема была именно в DPI-обработке.
|
||||
|
||||
### 17.1.2. Send RST off: отключение TCP Reset при блокировке протоколов
|
||||
|
||||
Параметр **send RST off** — важная настройка, определяющая поведение фильтра при блокировке распознанных протоколов.
|
||||
|
||||
| Значение | Поведение |
|
||||
| -------- | -------------------------------------------------------- |
|
||||
| **off** | TCP Reset при блокировке протоколов **не отправляется** |
|
||||
| **on** | TCP Reset отправляется абоненту и серверу при блокировке |
|
||||
|
||||
В проекте ТСПУ параметр **всегда должен быть в режиме `off`**.
|
||||
|
||||
**Почему отправка TCP Reset опасна:**
|
||||
|
||||
Когда приложение абонента (например, Telegram) пытается установить TCP-соединение и получает в ответ TCP Reset, оно воспринимает это как временный сбой и **немедленно** пытается установить новое соединение. Этот цикл повторяется непрерывно и с высокой частотой:
|
||||
|
||||
1. Приложение отправляет TCP SYN;
|
||||
2. Фильтр распознаёт протокол и отправляет TCP Reset;
|
||||
3. Приложение мгновенно пытается установить новое соединение;
|
||||
4. Цикл повторяется бесконечно.
|
||||
|
||||
На практике наблюдались случаи, когда мобильные устройства начинали **тормозить** из-за того, что Telegram непрерывно пытался переустановить заблокированную сессию. Количество генерируемых сессий создаёт **избыточную нагрузку** на фильтр.
|
||||
|
||||
При отключённой отправке Reset соединение **отбрасывается молча** — приложение пытается установить сессию, сессия «висит» и обрывается только по **тайм-ауту**. Это значительно снижает количество повторных попыток и нагрузку на фильтр.
|
||||
|
||||
### 17.1.3. Functionality mode: normal (не double mirror traffic)
|
||||
|
||||
| Значение | Описание | Применение в ТСПУ |
|
||||
| ------------------------- | -------------------------------------------- | ----------------- |
|
||||
| **normal** | Стандартный режим работы фильтра | **Всегда** |
|
||||
| **double mirror traffic** | Режим для работы с копией (зеркалом) трафика | Не используется |
|
||||
|
||||
Параметр **всегда должен быть `normal`**. Режим `double mirror traffic` предназначен для сценариев, когда фильтр получает зеркалированную копию трафика, что в проекте ТСПУ не применяется.
|
||||
|
||||
В секции DPI также присутствует устаревшая команда `extra analysis off` — она не используется и не требует внимания.
|
||||
|
||||
## 17.2. Настройка реестра РКН
|
||||
|
||||
Секция настройки реестра Роскомнадзора определяет параметры скачивания и обработки списков блокировки, предоставляемых Роскомнадзором.
|
||||
|
||||
> **Примечание:** в федеральном проекте эта секция вынесена в отдельный раздел конфигурации. В пилотном проекте (Урал) настройки находятся внутри DPI-листа 0.
|
||||
|
||||
### 17.2.1. Источник: RKN или ГРФЦ
|
||||
|
||||
| Источник | Описание |
|
||||
| -------- | ----------------------------------------------------------------------- |
|
||||
| **RKN** | Оригинальный формат выгрузки с серверов Роскомнадзора |
|
||||
| **ГРФЦ** | Новый формат выгрузки (оптимизированная база данных, уменьшенный объём) |
|
||||
|
||||
Роскомнадзор предложил новый источник списков — **ГРФЦ**. По сравнению с оригинальным форматом RKN, база данных ГРФЦ оптимизирована и уменьшена в объёме. Рекомендуется переключаться на выгрузку с ГРФЦ.
|
||||
|
||||
### 17.2.2. Логин/пароль для доступа к серверу РКН
|
||||
|
||||
Для скачивания реестра с сервера Роскомнадзора требуется **авторизация**. Логин и пароль задаются в секции настройки реестра. Учётные данные выдаются Роскомнадзором.
|
||||
|
||||
### 17.2.3. Привязка к DPI-листу (list number)
|
||||
|
||||
Параметр **list number** определяет, к какому DPI-листу будет привязан реестр Роскомнадзора. По умолчанию — **0**. В текущей конфигурации проекта ТСПУ фильтрация по реестру Роскомнадзора осуществляется в **DPI-листе 0**.
|
||||
|
||||
### 17.2.4. Proxy-сервер, dump server
|
||||
|
||||
| Параметр | Описание |
|
||||
| ---------------- | --------------------------------------------------------------------------------- |
|
||||
| **Proxy server** | Промежуточный сервер для доступа к реестру РКН, если прямое соединение невозможно |
|
||||
| **Dump server** | Сервер, на который фильтр выгружает скачанный реестр для внешнего анализа |
|
||||
|
||||
**Proxy server** используется, когда фильтр не может напрямую подключиться к серверу Роскомнадзора.
|
||||
|
||||
**Dump server** полезен для диагностики: можно получить копию того же дампа, который скачал фильтр, и проанализировать его на внешнем сервере. Фильтр скачивает реестр, а затем выгружает его на указанный dump server.
|
||||
|
||||
### 17.2.5. Проблемы скачивания: минимальная скорость ~10 Мбит/с
|
||||
|
||||
Сервер Роскомнадзора настроен таким образом, что **разрывает соединение** при низкой скорости скачивания. Эмпирически установлено, что минимальная скорость загрузки для успешного скачивания реестра составляет **~10 Мбит/с**. При более низкой скорости сервер Роскомнадзора обрывает соединение через некоторое время.
|
||||
|
||||
**Типичные причины проблем со скачиванием:**
|
||||
|
||||
- Недостаточная скорость management-интерфейса;
|
||||
- Ошибки на интерфейсе фильтра (в одном случае проблема решилась перезагрузкой фильтра);
|
||||
- Проблемы на стороне коммутатора или промежуточного оборудования.
|
||||
|
||||
При диагностике проблем скачивания следует обращать внимание на скорость и ошибки на management-интерфейсе. Команда `dpi run` позволяет принудительно инициировать обновление всех DPI-листов (подробнее — в [разделе 18.13.4](18.md)).
|
||||
|
||||
> **Примечание:** запуск `dpi run` не гарантирует, что реестр будет скачан — сервер РКН может ответить, что обновлений нет, и в этом случае ничего скачано не будет.
|
||||
|
||||
## 17.3. Деградация протоколов (protocols capacity)
|
||||
|
||||
Механизм деградации протоколов позволяет **частично ухудшить** работу распознанного протокола вместо полной блокировки. Настройка выполняется в секции DPI для каждого протокола индивидуально.
|
||||
|
||||
### 17.3.1. Шкала 0–100: 0 = полная блокировка, 100 = полный пропуск
|
||||
|
||||
Для каждого протокола задаётся значение **capacity** в условных единицах от 0 до 100:
|
||||
|
||||
| Значение | Поведение |
|
||||
| -------- | ------------------------------------------------- |
|
||||
| **0** | Полная блокировка — ничего не пропускается |
|
||||
| **100** | Полное пропускание — трафик не затрагивается |
|
||||
| **1–99** | Деградация — дроп пакетов с заданной вероятностью |
|
||||
|
||||
### 17.3.2. Дроп пакетов с заданной вероятностью
|
||||
|
||||
Механизм деградации работает просто: с определённой вероятностью, зависящей от параметра capacity, фильтр **дропает пакеты** в рамках сессии распознанного протокола. Чем ниже значение capacity, тем больше пакетов отбрасывается.
|
||||
|
||||
### 17.3.3. Эффективная деградация: 2–10% пропускания
|
||||
|
||||
На практике деградация становится **заметной для пользователя** только при значениях capacity в диапазоне **2–10**. Это объясняется свойствами TCP:
|
||||
|
||||
- TCP обладает встроенным механизмом **повторной передачи** потерянных пакетов;
|
||||
- При низкой степени деградации (высоких значениях capacity) TCP успешно компенсирует потери, и пользователь практически ничего не замечает;
|
||||
- Только при высокой степени деградации (capacity ~2–10) потери становятся настолько значительными, что TCP не успевает их компенсировать.
|
||||
|
||||
При значении capacity около **5** задержка отправки сообщений в приложениях может достигать **десятков секунд**.
|
||||
|
||||
### 17.3.4. Влияние на голосовые вызовы и мессенджеры
|
||||
|
||||
Деградация протоколов особенно эффективна для **голосовых вызовов** и **видеозвонков**, где потеря пакетов непосредственно влияет на качество:
|
||||
|
||||
- **Заикание** голоса и пропадание звука;
|
||||
- **Рассинхронизация** аудио и видео;
|
||||
- **Невозможность разговаривать** при высокой степени деградации;
|
||||
- Для текстовых сообщений — значительные **задержки доставки**.
|
||||
|
||||
Деградация является альтернативой полной блокировке: вместо немедленного и очевидного отключения сервиса пользователь получает **постепенное ухудшение** качества связи.
|
||||
|
||||
## 17.4. Настройка DPI-листов (0–16)
|
||||
|
||||
На фильтре может быть настроено до **16 DPI-листов** (номера 0–15). В будущих прошивках это количество может быть расширено — планируется возможность генерации DPI-листов по необходимости на уровне конфигурации.
|
||||
|
||||
Все DPI-листы имеют **одинаковую структуру** настроек (в федеральном проекте). Каждый лист настраивается индивидуально.
|
||||
|
||||
### 17.4.1. Enable/disable каждого листа
|
||||
|
||||
Каждый DPI-лист может быть **включён или выключен** независимо от остальных:
|
||||
|
||||
```text
|
||||
dpi list <N>
|
||||
enable ← включить лист
|
||||
disable ← выключить лист
|
||||
```
|
||||
|
||||
### 17.4.2. BitTorrent UTP detection
|
||||
|
||||
| Значение | Описание |
|
||||
| -------- | ----------------------------------------------- |
|
||||
| **on** | Включено распознавание протокола BitTorrent UTP |
|
||||
| **off** | Распознавание BitTorrent UTP выключено |
|
||||
|
||||
Если требуется распознавание и блокировка BitTorrent, параметр должен быть включён (`on`).
|
||||
|
||||
### 17.4.3. WH List Mode: blacklist (по умолчанию) / whitelist
|
||||
|
||||
Параметр **WH list mode** определяет логику работы DPI-листа:
|
||||
|
||||
| Режим | Поведение | Применение в ТСПУ |
|
||||
| ------------- | ----------------------------------------------------------------- | ----------------- |
|
||||
| **blacklist** | Всё, что совпало со списком — блокируется; остальное пропускается | **По умолчанию** |
|
||||
| **whitelist** | Пропускается только совпавший трафик; всё остальное блокируется | Не используется |
|
||||
|
||||
В проекте ТСПУ режим whitelist **не используется** из-за риска **случайной блокировки всего трафика**. Этот режим применяется в других сценариях, например, при использовании BRAS-функциональности на устройстве.
|
||||
|
||||
### 17.4.4. Behavior: block / ignore / color / redirect
|
||||
|
||||
Параметр **behavior** определяет, что происходит с трафиком, совпавшим со списком данного DPI-листа:
|
||||
|
||||
| Значение | Описание | Применение в ТСПУ |
|
||||
| ------------ | -------------------------------------------------------- | ---------------------------- |
|
||||
| **block** | Трафик блокируется (дропается) | Основной рабочий режим |
|
||||
| **ignore** | Совпадение фиксируется и логируется, трафик пропускается | Для распознавания протоколов |
|
||||
| **color** | Совпавший трафик «окрашивается» | Не используется |
|
||||
| **redirect** | Трафик перенаправляется | Не используется |
|
||||
|
||||
**Режим block** — основной для блокировки по реестру Роскомнадзора и по очищенным протокольным спискам. При срабатывании блокировки:
|
||||
|
||||
- Для **HTTP**: абоненту отправляется HTTP-редирект (302) на страницу-заглушку;
|
||||
- Для **HTTPS**: абоненту и серверу отправляется TCP Reset, разрывающий соединение (поскольку содержимое зашифровано и подмена ответа невозможна).
|
||||
|
||||
**Режим ignore** — используется для **первой стадии двухстадийной блокировки**: фильтр распознаёт протоколы и отправляет логи на SPFS, но сам трафик не блокирует. Данные передаются в ЦСУ для формирования очищенных списков (подробнее — в [разделе 8](08.md)).
|
||||
|
||||
Также в секции DPI-листа присутствует параметр **logs on/off** — включение журналирования срабатываний данного списка. В проекте ТСПУ эта функциональность, как правило, используется.
|
||||
|
||||
### 17.4.5. Redirect URL — страница-заглушка для заблокированных HTTP-ресурсов
|
||||
|
||||
Параметр **redirect URL** задаёт адрес страницы-заглушки, на которую перенаправляется абонент при блокировке **HTTP-ресурса** по реестру Роскомнадзора.
|
||||
|
||||
Типичное содержимое страницы-заглушки: уведомление абонента о том, что запрошенный ресурс заблокирован в соответствии с требованиями законодательства.
|
||||
|
||||
> **Важно:** redirect URL работает **только для HTTP-трафика**. Для HTTPS-трафика перенаправление невозможно (содержимое зашифровано), поэтому используется TCP Reset.
|
||||
|
||||
Также в секции DPI-листа присутствуют параметры, связанные с redirect behavior (redirect interval и др.) — в проекте ТСПУ они **не используются**.
|
||||
|
||||
### 17.4.6. Download URL — источник списков, update schedule
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------------- | -------------------------------------------------------------------- |
|
||||
| **Download URL** | URL, откуда фильтр скачивает список фильтрации для данного DPI-листа |
|
||||
| **Update schedule** | Интервал обновления списка (например, 30 минут) |
|
||||
|
||||
Download URL задаёт источник списков для DPI-листов, **не связанных** с реестром Роскомнадзора (скачивание реестра РКН настраивается отдельно — см. [раздел 17.2](#172-настройка-реестра-ркн)). Типичный источник — ресурс в **центральной системе управления** (ЦСУ), откуда загружаются очищенные протокольные списки.
|
||||
|
||||
**Update schedule** определяет частоту обновления:
|
||||
|
||||
| Значение | Поведение |
|
||||
| ------------ | -------------------------------------------------- |
|
||||
| Время (мин.) | Список обновляется с заданным интервалом |
|
||||
| **never** | Список **никогда не обновляется** и не скачивается |
|
||||
|
||||
> **Внимание:** значение `never` — частая причина проблем. Если всё настроено корректно, но update schedule установлен в `never`, списки просто не будут скачиваться. Необходимо задать конкретный интервал обновления.
|
||||
|
||||
### 17.4.7. Protocols — список распознаваемых протоколов
|
||||
|
||||
В секции **protocols** каждого DPI-листа указываются протоколы, по которым будет осуществляться распознавание и последующее действие (блокировка, игнорирование и т.д.).
|
||||
|
||||
Список протоколов задаётся перечислением названий: Telegram, WhatsApp, Viber, BitTorrent и др. Набор поддерживаемых протоколов определяется версией прошивки фильтра.
|
||||
|
||||
### 17.4.8. No IP / IP — исключение/включение адресов для обработки
|
||||
|
||||
Параметры **IP** и **No IP** определяют, какой трафик подлежит обработке данным DPI-листом:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ---------------------- | --------------------------------------------------------------------- |
|
||||
| **IP** | Подсети и адреса, которые **должны обрабатываться** данным DPI-листом |
|
||||
| **No IP** | Локальные адреса абонентов, **исключённые** из обработки |
|
||||
| **No IP Remote** | Удалённые адреса (серверы), **исключённые** из обработки |
|
||||
| **IPv6** / **No IPv6** | Аналогичные параметры для IPv6-трафика |
|
||||
|
||||
По умолчанию параметр **IP** должен содержать сеть `0.0.0.0/0` для всех VLAN — тогда весь трафик, попавший в DPI, будет обрабатываться данным листом.
|
||||
|
||||
**Использование No IP для диагностики:**
|
||||
|
||||
Параметр **No IP** — ключевой инструмент траблшутинга. Чтобы проверить, влияет ли данный DPI-лист на конкретного абонента:
|
||||
|
||||
1. Добавить локальный IP-адрес абонента в **No IP** данного DPI-листа;
|
||||
2. Выполнить `apply`;
|
||||
3. Проверить, изменилось ли поведение у абонента;
|
||||
4. Если приложение у абонента **заработало** — данный DPI-лист действительно блокировал его трафик;
|
||||
5. Если **ничего не изменилось** — проблема не в данном DPI-листе.
|
||||
|
||||
Параметр **No IP Remote** работает аналогично, но исключает из обработки удалённый IP-адрес (адрес сервера).
|
||||
|
||||
### 17.4.9. QUIC list
|
||||
|
||||
Параметр **QUIC list** определяет список ресурсов, для которых должен распознаваться протокол **QUIC** (Quick UDP Internet Connections) — протокол, разработанный Google для оптимизации доставки контента.
|
||||
|
||||
Фильтр **умеет распознавать** QUIC, но для этого необходимо внести ресурсы, которые планируется обрабатывать, в QUIC list.
|
||||
|
||||
## 17.5. Формат списков фильтрации
|
||||
|
||||
Списки фильтрации (кроме реестра Роскомнадзора, который скачивается в специальном формате) представляют собой **текстовые файлы**, где на каждой строке перечислены ресурсы для обработки.
|
||||
|
||||
### 17.5.1. IP-адреса, подсети, диапазоны, URL
|
||||
|
||||
Поддерживаемые форматы записей в списках:
|
||||
|
||||
| Формат | Пример | Описание |
|
||||
| ------------------- | ------------------------- | ---------------------- |
|
||||
| IP-адрес | `1.2.3.4` | Конкретный IP-адрес |
|
||||
| Подсеть | `10.0.0.0/8` | Подсеть в CIDR-нотации |
|
||||
| Диапазон IP | `1.2.3.4-1.2.3.10` | Диапазон адресов |
|
||||
| URL | `http://example.com/page` | Конкретный URL (HTTP) |
|
||||
| Домен | `example.com` | Домен (HTTP и HTTPS) |
|
||||
| Домен с поддоменами | `*.example.com` | Домен и все поддомены |
|
||||
|
||||
Если в начале URL стоит **звёздочка** (`*`), обрабатываются **все протоколы** (HTTP и HTTPS) и **все поддомены** данного домена. Если протокол **не указан явно**, обрабатываются и HTTP, и HTTPS.
|
||||
|
||||
### 17.5.2. HTTP: блокировка конкретного URL
|
||||
|
||||
Для **HTTP**-трафика возможна блокировка **конкретного URL** — вплоть до отдельной страницы. Это обусловлено тем, что при HTTP-соединении URL передаётся **в открытом виде** в заголовке запроса, и фильтр может его проанализировать.
|
||||
|
||||
Пример: запись `http://example.com/specific/page.html` в списке заблокирует **только эту конкретную страницу**, остальные страницы на `example.com` останутся доступными.
|
||||
|
||||
### 17.5.3. HTTPS: блокировка только по домену (SNI/Client Hello)
|
||||
|
||||
Для **HTTPS**-трафика блокировка возможна **только на уровне домена**. Это фундаментальное ограничение, связанное с механизмом установления HTTPS-соединения:
|
||||
|
||||
1. При установлении HTTPS-соединения клиент отправляет **Client Hello**;
|
||||
2. В Client Hello содержится поле **SNI** (Server Name Indication), указывающее доменное имя сервера;
|
||||
3. Поле SNI содержит **только домен** (например, `ru.wikipedia.org`) — **без пути и URL**;
|
||||
4. Всё остальное содержимое HTTPS-соединения **зашифровано** и недоступно для анализа.
|
||||
|
||||
**Практическое следствие:** если в списке указана строка вида `https://ru.wikipedia.org/wiki/Конкретная_статья`, фильтр заблокирует **весь домен** `ru.wikipedia.org` целиком, а не конкретную страницу. Поле SNI не содержит пути URL, поэтому фильтр видит только домен и блокирует все обращения к нему.
|
||||
|
||||
| Протокол | Точность блокировки | Причина |
|
||||
| --------- | --------------------------- | ------------------------------------- |
|
||||
| **HTTP** | До конкретного URL/страницы | URL виден в открытом виде в заголовке |
|
||||
| **HTTPS** | Только весь домен целиком | В SNI (Client Hello) только домен |
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 16: Фильтр: ACL и пулы](16.md) · [Раздел 18: Фильтр: мониторинг и диагностика →](18.md)
|
||||
326
18.md
Normal file
326
18.md
Normal file
@@ -0,0 +1,326 @@
|
||||
# 18. Фильтр: мониторинг и диагностика
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md)
|
||||
|
||||
---
|
||||
|
||||
Фильтр предоставляет обширный набор команд мониторинга и диагностики, позволяющих оценить состояние аппаратной части, загрузку ресурсов, статистику обработки трафика и работу модуля DPI. Все команды мониторинга выполняются в **операционном режиме** (приглашение `>`), за исключением ping и traceroute, которые доступны из **конфигурационного режима**.
|
||||
|
||||
## 18.1. `show version` — версия ПО, серийный номер (= MAC management)
|
||||
|
||||
Команда `show version` отображает информацию о текущей версии программного обеспечения фильтра:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------- | ----------------------------------------------------------- |
|
||||
| **Версия ПО** | Основной номер версии (например, `3.14.040 BP`) |
|
||||
| **Серийный номер** | Серийный номер платформы — необходим при обращении в техподдержку |
|
||||
|
||||
Команда `show version detail` дополнительно выводит хэши сборки, указывающие на конкретный коммит в сборочной системе (полезно для разработчиков).
|
||||
|
||||
> **Важно:** серийный номер платформы **совпадает** с MAC-адресом management-интерфейса. Это можно проверить через команду `show ip if`.
|
||||
|
||||
## 18.2. `show ip if` — параметры management-интерфейса
|
||||
|
||||
Команда отображает параметры management-интерфейса:
|
||||
|
||||
- **MAC-адрес** (совпадает с серийным номером);
|
||||
- **IP-адрес**;
|
||||
- **Маска подсети**;
|
||||
- **Default gateway**.
|
||||
|
||||
## 18.3. `show time` — текущее время (UTC / local)
|
||||
|
||||
Команда выводит текущее время в двух форматах:
|
||||
|
||||
- **UTC** — всемирное координированное время;
|
||||
- **Local** — локальное время (с учётом настроенного сдвига).
|
||||
|
||||
Оба значения отображаются всегда, даже если они совпадают.
|
||||
|
||||
## 18.4. `show uptime` — время работы платформы и процесса EcoNAT
|
||||
|
||||
Команда показывает **два значения** времени работы:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ----------------------- | --------------------------------------------------------- |
|
||||
| **Uptime платформы** | Время с момента включения/перезагрузки аппаратной платформы |
|
||||
| **Uptime EcoNAT** | Время с момента запуска процесса обработки трафика |
|
||||
|
||||
Эти два значения могут отличаться на **небольшую величину** (обычно до 1 минуты): сначала стартует платформа, затем — процесс EcoNAT, который инициализирует интерфейсы и начинает обработку трафика.
|
||||
|
||||
> **Примечание:** после старта EcoNAT обновляет время по NTP. В некоторых случаях это приводит к тому, что в выводе `show uptime` отображаются **некорректные значения**. Например, если в BIOS было установлено неверное время, после синхронизации по NTP вывод uptime может показывать аномальные цифры. Это нормальная ситуация — значения восстановятся после следующей перезагрузки. Тем не менее, подобные аномалии следует исследовать.
|
||||
|
||||
## 18.5. Аппаратная часть: `show power`, `show fan`, `show temperature`
|
||||
|
||||
### show power
|
||||
|
||||
Отображает состояние **источников питания**: `OK` или `FAIL`. В будущих версиях прошивки планируется более подробный вывод — напряжение на входе, мощность блоков питания, внутренние параметры (вольты, ватты, амперы).
|
||||
|
||||
### show fan
|
||||
|
||||
Отображает **скорость вращения вентиляторов**:
|
||||
|
||||
- **Системные вентиляторы** — обычно 4 штуки, каждый с двумя датчиками;
|
||||
- **Вентиляторы на сетевых картах** — отдельные показания.
|
||||
|
||||
### show temperature
|
||||
|
||||
Отображает **температуру ядер процессора** (не крышки и не внешнего сенсора):
|
||||
|
||||
| Диапазон | Оценка |
|
||||
| ------------- | --------------------------------------------------------- |
|
||||
| **40–50 °C** | Нормальные значения |
|
||||
| **~70 °C** | Платформа начинает перегреваться — необходимо проверить условия охлаждения на площадке |
|
||||
|
||||
При обнаружении повышенной температуры следует запросить у оператора информацию о состоянии окружающей среды на площадке (кондиционирование, вентиляция).
|
||||
|
||||
## 18.6. Интерфейсы: `show interface brief`, traffic monitor, трансиверы (DDM)
|
||||
|
||||
### show interface brief
|
||||
|
||||
Выводит **краткую информацию** по всем интерфейсам:
|
||||
|
||||
| Поле | Описание |
|
||||
| --------------- | ----------------------------------------------- |
|
||||
| **Состояние** | Up / Down |
|
||||
| **MTU** | Текущее значение MTU на интерфейсе |
|
||||
| **MAC** | MAC-адрес интерфейса |
|
||||
| **Скорость** | Скорость линка |
|
||||
| **Loading** | Условная загрузка интерфейса в процентах |
|
||||
| **Description** | Описание интерфейса (если задано) |
|
||||
|
||||
### Traffic monitor
|
||||
|
||||
Команда `show interface <имя|all> traffic monitor` выводит **ежесекундно обновляемую таблицу** с текущей нагрузкой на интерфейсы:
|
||||
|
||||
- Количество **байт** — принятых и переданных за последнюю секунду;
|
||||
- Количество **пакетов** — на вход и на выход;
|
||||
- **Ошибки** — всегда должны быть нулевыми.
|
||||
|
||||
Для выхода из режима мониторинга — `Ctrl+C`.
|
||||
|
||||
Команда `show interface all traffic` (без слова `monitor`) показывает **суммарные счётчики** в байтах и пакетах с момента последней очистки или перезагрузки.
|
||||
|
||||
### Трансиверы (DDM)
|
||||
|
||||
Фильтр позволяет просмотреть информацию о подключённых **трансиверах** и уровни оптических сигналов (**DDM** — Digital Diagnostic Monitoring):
|
||||
|
||||
- Информация доступна для **оптических модулей**;
|
||||
- Для **медных модулей** и **direct-attach кабелей** DDM не поддерживается;
|
||||
- Поддерживаются трансиверы **любых производителей**, совместимых с чипами Intel на сетевых картах фильтра. Программных ограничений на вендора нет, однако совместимость может быть ограничена самим чипом Intel.
|
||||
|
||||
## 18.7. Ресурсы: `show resources`
|
||||
|
||||
Команда `show resources` — **основная команда** для оценки загрузки фильтра. Выводит загрузку процессора, ресурсных таблиц и DPI.
|
||||
|
||||
### 18.7.1. Таблицы сессий/трансляций: не более 20% загрузки
|
||||
|
||||
Загрузка ресурсных таблиц (сессий, трансляций, IPv6-сессий) отображается в **процентах** от максимального объёма. Критический порог — **20%**.
|
||||
|
||||
| Загрузка | Оценка |
|
||||
| ------------ | ----------------------------------------------------------- |
|
||||
| **< 20%** | Нормальная работа |
|
||||
| **> 20%** | Превышена оптимальная загрузка — поиск по таблице замедляется |
|
||||
|
||||
Превышение порога в 20% приводит к **существенному росту задержек** при обработке трафика. Это связано с внутренней архитектурой хэш-таблиц: при высокой заполненности поиск по ним становится значительно дольше, и часть трафика может не успевать обрабатываться.
|
||||
|
||||
**Что делать при превышении 20%:**
|
||||
|
||||
- Обратиться в техподдержку;
|
||||
- Вероятная причина — на фильтр попало **больше трафика**, чем планировалось (таблицы рассчитаны на определённую полосу пропускания);
|
||||
- Возможная причина — **DDoS-атака**: маленькие пакеты генерируют огромное количество сессий при небольшом объёме трафика;
|
||||
- Запросить у оператора информацию о состоянии трафика.
|
||||
|
||||
> **Примечание:** таблица абонентов (subscribers) также отображается в `show resources`, но в проекте ТСПУ **не используется** — это функционал BRAS.
|
||||
|
||||
### 18.7.2. Свободные буферы: не должны уходить в ноль
|
||||
|
||||
Значение **свободных буферов** не имеет конкретного «правильного» числа. Важно следить за **динамикой**:
|
||||
|
||||
- Буферы могут увеличиваться и уменьшаться в зависимости от нагрузки;
|
||||
- На графике они должны **колебаться** вокруг средней линии;
|
||||
- Если в течение **недели и более** буферы постепенно **уменьшаются** — это признак **утечки памяти**, и необходимо открывать кейс в техподдержке;
|
||||
- Буферы **не должны уходить в ноль**.
|
||||
|
||||
### 18.7.3. DPI-ресурсы: не более 100%
|
||||
|
||||
Загрузка DPI-ресурсов отображается отдельно. Порог — **100%**:
|
||||
|
||||
| Загрузка | Оценка |
|
||||
| -------------- | -------------------------- |
|
||||
| **< 100%** | Нормальная работа |
|
||||
| **≥ 100%** | Ресурсы DPI исчерпаны |
|
||||
|
||||
### 18.7.4. CPU Load — условный параметр обработки трафика
|
||||
|
||||
Параметр **CPU Load** в `show resources` — это **не** стандартная загрузка CPU в понимании Linux. Это **условный параметр**, рассчитываемый процессом EcoFilter, отражающий долю времени, затрачиваемую на обработку трафика.
|
||||
|
||||
| Загрузка | Оценка |
|
||||
| -------------- | -------------------------------------------------------- |
|
||||
| **< 80%** | Нормальная работа |
|
||||
| **80–90%** | Повод для анализа — выяснить причину высокой загрузки |
|
||||
| **~100%** | Критическая ситуация — фильтр не справляется |
|
||||
|
||||
Значения 80–90% и выше — повод обратиться в техподдержку или провести собственное расследование причин.
|
||||
|
||||
## 18.8. Память: Control Plane vs Data Plane
|
||||
|
||||
Память фильтра условно разделена на **две области**:
|
||||
|
||||
| Область | Назначение |
|
||||
| -------------------- | ------------------------------------------------------------- |
|
||||
| **Control Plane** | ОС Linux, CLI, сервисные функции (syslog, управление и т.д.) |
|
||||
| **Data Plane** | Процесс EcoNAT — обработка трафика, ресурсные таблицы |
|
||||
|
||||
### 18.8.1. Data Plane выделяется при старте, не должна расти
|
||||
|
||||
Память Data Plane выделяется **один раз при старте** процесса EcoNAT. В ней создаются ресурсные таблицы (сессии, трансляции и пр.).
|
||||
|
||||
После старта объём занятой Data Plane памяти **не должен расти**. На графике мониторинга это должна быть **ровная линия** с незначительными отклонениями. Если наблюдается постоянный рост — это признак утечки памяти.
|
||||
|
||||
### 18.8.2. Пороги: 5–10% свободной памяти — повод для тревоги
|
||||
|
||||
| Свободная память | Оценка |
|
||||
| ---------------- | --------------------------------------------------------- |
|
||||
| **> 10%** | Нормально |
|
||||
| **5–10%** | Повод для тревоги — рекомендуется настроить алерт в системе мониторинга |
|
||||
| **< 5%** | Критическая ситуация |
|
||||
|
||||
Если свободная память составляет 5%, но **не уменьшается** со временем — это нормальная ситуация. На современных платформах памяти достаточно, и свободной памяти обычно остаётся много.
|
||||
|
||||
> **Примечание:** на некоторых площадках (например, МТС) используется другой принцип расчёта свободной памяти, и в мониторинге могут отображаться небольшие значения (~5%). Это нормально для данных прошивок.
|
||||
|
||||
## 18.9. `show cps` — скорость создания новых сессий
|
||||
|
||||
Команда `show cps` (Connections Per Second) показывает **скорость создания новых сессий** и трансляций в секунду.
|
||||
|
||||
| Значение | Интерпретация |
|
||||
| ----------- | ----------------------------------------------------------- |
|
||||
| **> 0** | Новые сессии создаются, трафик обрабатывается |
|
||||
| **0** | Новые сессии не создаются — требуется диагностика |
|
||||
|
||||
**Нулевое значение** может означать:
|
||||
|
||||
1. **Трафик не проходит** через фильтр вообще;
|
||||
2. **Трафик проходит, но не попадает в пул** — ACL не отбирает трафик, сессии не создаются. Через фильтр могут идти гигабиты и десятки гигабит, но `show cps` будет показывать ноль (подробнее — в [разделе 16](16.md)).
|
||||
|
||||
## 18.10. `show statistic` — статистика сессий и пулов, значение Optimal (= 20%)
|
||||
|
||||
Команда `show statistic` отображает статистику по сессиям и загрузке пула:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------ | ----------------------------------------------------------- |
|
||||
| **Total** | Максимальный размер таблицы |
|
||||
| **Used** | Количество используемых записей |
|
||||
| **Optimal** | 20% от Total — оптимальный максимум загрузки |
|
||||
|
||||
Значение **Optimal** — это те же 20%, что и в `show resources`, но отображённые **в абсолютных числах**, а не в процентах. Количество используемых записей (Used) **не должно превышать** значение Optimal.
|
||||
|
||||
Загрузка пула: поскольку пул в проекте ТСПУ всегда типа **fake**, его загрузка будет **нулевой** — на неё можно не обращать внимания.
|
||||
|
||||
## 18.11. Счётчики: `show counters all` / `show counters div` (дельта за секунду)
|
||||
|
||||
На фильтре существует **большое количество** счётчиков — практически на каждую операцию.
|
||||
|
||||
| Команда | Описание |
|
||||
| ---------------------- | ---------------------------------------------------------- |
|
||||
| `show counters all` | Значения счётчиков с момента последнего обнуления (или перезагрузки) |
|
||||
| `show counters div` | Дельта за последнюю секунду — какие счётчики увеличились и на сколько |
|
||||
|
||||
**`show counters div`** — наиболее полезная команда для оперативной диагностики. Она показывает только те счётчики, которые **изменились за последнюю секунду**. Если счётчик не появился в выводе — значит, за последнюю секунду он не увеличился.
|
||||
|
||||
Примеры счётчиков:
|
||||
|
||||
- Распознанные пакеты по протоколам (WhatsApp Voice, Telegram и т.д.);
|
||||
- Отправленные логи;
|
||||
- Счётчики L2-протоколов (PPPoE, MPLS);
|
||||
- Нераспознанные протоколы;
|
||||
- И многие другие (сотни счётчиков).
|
||||
|
||||
Как правило, из названия счётчика понятно, за что он отвечает. Наиболее важные счётчики выведены в **систему мониторинга**. На разных площадках набор активных счётчиков может различаться в зависимости от типа трафика и инкапсуляций.
|
||||
|
||||
> **Подсказка:** для оценки нераспознанного трафика можно сравнить **общее количество пакетов** с суммой распознанных — разница покажет объём нераспознанного трафика.
|
||||
|
||||
## 18.12. Системный журнал: `show syslog`, ротация двух файлов
|
||||
|
||||
Помимо логирования на внешний сервер (см. [раздел 14.8](14.md)), логи хранятся **внутри устройства** на локальном разделе.
|
||||
|
||||
Особенности внутреннего хранения:
|
||||
|
||||
- Раздел для логов **небольшой**;
|
||||
- Используются **два файла**, которые **ротируются**: сначала пишется в один, затем в другой, и наоборот;
|
||||
- При большом объёме логов файлы **быстро перезатираются** — если с момента проблемы прошло пару суток, логи, скорее всего, уже утрачены;
|
||||
- Именно для решения этой проблемы в федеральном проекте добавлено **внешнее логирование** на СПХД.
|
||||
|
||||
Команда `show syslog` выводит записи из внутреннего журнала, начиная с **самых свежих**.
|
||||
|
||||
## 18.13. DPI-мониторинг
|
||||
|
||||
### 18.13.1. `show dpi records <N>` — содержимое DPI-листа
|
||||
|
||||
Команда `show dpi records <N>` выводит **содержимое** загруженного DPI-листа с номером N, включая реестр Роскомнадзора (лист 0).
|
||||
|
||||
> **Предупреждение:** содержимое реестра Роскомнадзора (лист 0) **очень велико**. Вывод может продолжаться несколько минут. Для прерывания — `Ctrl+C`.
|
||||
|
||||
### 18.13.2. `show dpi state` — количество записей, дата последнего дампа
|
||||
|
||||
Команда `show dpi state` — **основная диагностическая команда** для анализа состояния DPI. Отображает:
|
||||
|
||||
| Параметр | Описание |
|
||||
| ------------------------- | --------------------------------------------------------- |
|
||||
| **Количество IP-записей** | Число загруженных IP-адресов и подсетей |
|
||||
| **Количество URL-записей**| Число загруженных URL |
|
||||
| **Last time** | Время последнего скачивания дампа |
|
||||
| **Actual date for delta** | Временная метка последней записи в реестре Роскомнадзора |
|
||||
| **DPI-ресурсы** | Загрузка ресурсов DPI (аналогично `show resources`) |
|
||||
|
||||
**Интерпретация дат:**
|
||||
|
||||
Реестр Роскомнадзора формируется **итерационно**: Роскомнадзор периодически обновляет реестр, выпуская основные дампы и дельты. Если Роскомнадзор **не вносил обновлений** в течение длительного времени (например, суток), то:
|
||||
|
||||
- Фильтр продолжает запрашивать обновления с периодичностью update schedule (обычно 30 минут);
|
||||
- Сервер РКН отвечает, что обновлений нет;
|
||||
- Дата последнего скачивания **не обновляется**;
|
||||
- В системе мониторинга может появиться алерт «дамп не скачивался более 24 часов».
|
||||
|
||||
Это **не обязательно означает проблему** — возможно, Роскомнадзор просто не обновлял реестр. Однако если дата не обновляется длительное время, следует проверить скорость скачивания и доступность сервера РКН.
|
||||
|
||||
Команда `dpi list` показывает файлы на диске: все дампы, дельты и сформированные DPI-листы. Например, реестр Роскомнадзора после парсинга хранится в файле `list_0.dpi`.
|
||||
|
||||
### 18.13.3. `dpi load <N>` — ручная загрузка списка
|
||||
|
||||
Команда `dpi load <N>` принудительно загружает DPI-лист с номером N с URL, указанного в конфигурации данного листа (или с URL, заданного в команде). Используется для диагностики проблем с загрузкой списков.
|
||||
|
||||
### 18.13.4. `dpi run` — принудительное обновление всех списков
|
||||
|
||||
Команда `dpi run` принудительно запускает обновление **всех** настроенных DPI-листов. В штатной эксплуатации обычно не требуется — используется при диагностике проблем с обновлением списков.
|
||||
|
||||
> **Примечание:** `dpi run` инициирует запрос к серверам, но не гарантирует скачивание — если обновлений нет, ничего скачано не будет.
|
||||
|
||||
### 18.13.5. `show dpi match <ресурс>` — проверка ресурса по всем DPI-листам
|
||||
|
||||
Команда `show dpi match <ресурс>` проверяет указанный ресурс (IP-адрес или URL) по **всем загруженным DPI-листам** и выводит:
|
||||
|
||||
- В каком DPI-листе найдено **совпадение**;
|
||||
- Какое **поведение** (behavior) задано для этого листа.
|
||||
|
||||
Если совпадений нет — вывод будет пустым.
|
||||
|
||||
> **Примечание:** в версии прошивки пилотного проекта (Урал) эта команда может быть **недоступна**. Она появилась в более новых версиях для федерального проекта.
|
||||
|
||||
Команда крайне полезна для диагностики: если абонент жалуется на блокировку ресурса, можно быстро проверить, присутствует ли ресурс в каком-либо DPI-листе и с каким действием.
|
||||
|
||||
## 18.14. Ping и Traceroute (из конфигурационного режима)
|
||||
|
||||
Команды `ping` и `traceroute` доступны из **конфигурационного режима** (не из операционного).
|
||||
|
||||
| Команда | Описание |
|
||||
| --------------- | ----------------------------------------------------------- |
|
||||
| `ping <адрес>` | Бесконечный пинг до указанного хоста (прервать — `Ctrl+C`) |
|
||||
| `traceroute <адрес>` | Трассировка маршрута до хоста |
|
||||
|
||||
> **Важно:** ping и traceroute работают **только через management-интерфейс**. Фильтр — это L2-устройство без IP-интерфейсов в тракте данных, поэтому инициировать трафик через LAN/WAN-интерфейсы **невозможно** (подробнее — в [разделе 5.2](05.md)).
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 17: Фильтр: настройка DPI](17.md) · [Раздел 19: Фильтр: обновление прошивки →](19.md)
|
||||
120
19.md
Normal file
120
19.md
Normal file
@@ -0,0 +1,120 @@
|
||||
# 19. Фильтр: обновление прошивки
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md)
|
||||
|
||||
---
|
||||
|
||||
Обновление программного обеспечения фильтра выполняется через CLI из конфигурационного режима. Система хранения прошивок построена на принципе **двух равнозначных разделов**, что позволяет безопасно обновляться и при необходимости откатываться на предыдущую версию.
|
||||
|
||||
## 19.1. Два раздела: prim1 и prim2 (равнозначные) + FB (заводская)
|
||||
|
||||
На SSD-накопителе фильтра расположены **три раздела** для программного обеспечения:
|
||||
|
||||
| Раздел | Описание |
|
||||
| --------- | ---------------------------------------------------------------- |
|
||||
| **FB** | Заводская прошивка — минимальный образ, предоставляющий только доступ к management-интерфейсу и возможность загрузить нормальную прошивку |
|
||||
| **prim1** | Первый рабочий раздел для полноценной прошивки |
|
||||
| **prim2** | Второй рабочий раздел для полноценной прошивки |
|
||||
|
||||
Разделы **prim1** и **prim2** — **абсолютно равнозначные**. Нет «основного» и «второстепенного» — оба раздела одинаковы. На каждом может быть загружен свой образ ПО, и между ними можно свободно переключаться (с перезагрузкой).
|
||||
|
||||
## 19.2. `firmware status` — текущее состояние (cur / boot)
|
||||
|
||||
Команда `firmware status` (из конфигурационного режима) выводит информацию о разделах прошивки:
|
||||
|
||||
| Поле | Описание |
|
||||
| --------- | ----------------------------------------------------------- |
|
||||
| **cur** | Активная версия — та, с которой устройство работает сейчас |
|
||||
| **boot** | Версия, которая будет загружена при следующей перезагрузке |
|
||||
|
||||
Пример вывода: активная версия — `4031` (cur), после перезагрузки загрузится `4038` (boot). Это означает, что новая прошивка была установлена, но устройство ещё не перезагружено.
|
||||
|
||||
В нормальном рабочем состоянии значения **cur** и **boot** указывают на один и тот же раздел. После установки новой прошивки **boot** автоматически переключается на раздел с новой версией.
|
||||
|
||||
## 19.3. `firmware download` — скачивание, `firmware install` — установка
|
||||
|
||||
Обновление прошивки выполняется в **два этапа**:
|
||||
|
||||
### Этап 1: Скачивание
|
||||
|
||||
```text
|
||||
firmware download <URL>
|
||||
```
|
||||
|
||||
Команда скачивает образ прошивки с указанного URL на устройство.
|
||||
|
||||
### Этап 2: Установка
|
||||
|
||||
```text
|
||||
firmware install
|
||||
```
|
||||
|
||||
Команда устанавливает скачанный образ на **неактивный раздел** (тот, который сейчас не используется). После установки значение **boot** автоматически переключается на раздел с новой прошивкой.
|
||||
|
||||
**Важные ограничения:**
|
||||
|
||||
- Установка выполняется быстро (~5 секунд), но в этот момент фильтр может **не реагировать** на команды в CLI;
|
||||
- После установки, пока устройство не перезагружено, **повторная установка невозможна** — для установки новой прошивки значения cur и boot должны совпадать;
|
||||
- Для применения новой прошивки необходима **перезагрузка** устройства (из конфигурационного режима, с подтверждением).
|
||||
|
||||
### Полная последовательность обновления
|
||||
|
||||
```text
|
||||
# 1. Проверить текущее состояние
|
||||
firmware status
|
||||
|
||||
# 2. Скачать новую прошивку
|
||||
firmware download <URL>
|
||||
|
||||
# 3. Установить на неактивный раздел
|
||||
firmware install
|
||||
|
||||
# 4. Проверить, что boot указывает на новый раздел
|
||||
firmware status
|
||||
|
||||
# 5. Перезагрузить устройство
|
||||
reload
|
||||
```
|
||||
|
||||
## 19.4. `firmware rollback` / `firmware reset`
|
||||
|
||||
Для управления разделами загрузки доступны две команды:
|
||||
|
||||
| Команда | Действие |
|
||||
| --------------------- | ----------------------------------------------------------- |
|
||||
| **firmware rollback** | Переключает **boot** на неактивный раздел (откат на другую версию) |
|
||||
| **firmware reset** | Возвращает **boot** обратно на текущий активный раздел (отмена rollback) |
|
||||
|
||||
### firmware rollback
|
||||
|
||||
Команда `firmware rollback` меняет значение boot с активного раздела на неактивный. Это позволяет:
|
||||
|
||||
- **Откатиться** на предыдущую версию прошивки (если на другом разделе сохранена рабочая версия);
|
||||
- **Отменить** запланированное обновление (если после `firmware install` вы решили не обновляться).
|
||||
|
||||
### firmware reset
|
||||
|
||||
Команда `firmware reset` выполняет обратное действие — возвращает boot на текущий активный раздел. Используется, если rollback был выполнен по ошибке.
|
||||
|
||||
> **Примечание:** обе команды изменяют только указатель boot — фактического переключения не происходит до перезагрузки.
|
||||
|
||||
## 19.5. Централизованное обновление через ЦСУ
|
||||
|
||||
В промышленной эксплуатации обновление прошивок выполняется **централизованно** через центральную систему управления (ЦСУ):
|
||||
|
||||
- Оператор инициирует обновление через интерфейс ЦСУ;
|
||||
- ЦСУ автоматически скачивает и устанавливает прошивку на фильтры;
|
||||
- По завершении формируется **отчёт** об успешности или неуспешности обновления;
|
||||
- Перезагрузка фильтров также инициируется через ЦСУ.
|
||||
|
||||
Ручное обновление через CLI остаётся важным навыком для:
|
||||
|
||||
- Диагностики проблем с обновлением;
|
||||
- Обновления единичных устройств;
|
||||
- Работы на площадках, где ЦСУ временно недоступна.
|
||||
|
||||
При массовом обновлении множества фильтров через ЦСУ рекомендуется **последовательная** перезагрузка с проверкой работоспособности каждого устройства после обновления.
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 18: Фильтр: мониторинг и диагностика](18.md) · [Раздел 20: Балансировщик: аппаратная платформа →](20.md)
|
||||
175
20.md
Normal file
175
20.md
Normal file
@@ -0,0 +1,175 @@
|
||||
# 20. Балансировщик: аппаратная платформа
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md)
|
||||
|
||||
---
|
||||
|
||||
Балансировщик (EcoFilter Balancer) — устройство, обеспечивающее распределение трафика между фильтрами и их отказоустойчивость. Аппаратная платформа **одинакова** как для EcoFilter Balancer, так и для Eco Highway (эшелонированная система) — различия только в программной части.
|
||||
|
||||
## 20.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов)
|
||||
|
||||
Балансировщик выпускается в двух форм-факторах:
|
||||
|
||||
| Форм-фактор | Количество портов | Применение в ТСПУ |
|
||||
| ------------------ | -------------------- | ------------------ |
|
||||
| **1U** (одноюнитовый) | 32 порта QSFP28 | **Используется** |
|
||||
| **2U** (двухюнитовый) | 65 портов QSFP28 | Не используется |
|
||||
|
||||
В проекте ТСПУ применяются **только одноюнитовые** балансировщики с 32 портами QSFP28.
|
||||
|
||||
Характеристики:
|
||||
|
||||
- **Пропускная способность** — 3,2 Тбит/с на уровне провода (для пакетов более 160 байт);
|
||||
- **Питание** — два блока питания с горячим резервированием (расположены на задней панели);
|
||||
- **Высота** — 1U.
|
||||
|
||||
## 20.2. Скорости портов: 10G / 25G / 100G
|
||||
|
||||
Порты QSFP28 поддерживают работу на различных скоростях в зависимости от конфигурации и типа установленных трансиверов:
|
||||
|
||||
| Скорость | Описание |
|
||||
| ----------- | ------------------------------------------------------------ |
|
||||
| **100G** | Все 4 линии порта QSFP28 объединены (суммарная скорость) |
|
||||
| **25G** | Каждая из 4 линий работает отдельно на 25 Гбит/с |
|
||||
| **10G** | Каждая из 4 линий работает на 10 Гбит/с (с использованием гидры) |
|
||||
|
||||
В проекте ТСПУ типовые скорости — **10G** и **100G**.
|
||||
|
||||
Каждый физический порт QSFP28 разделён на **четыре линии** (lane 0–3), каждая из которых может работать на скорости до 25 Гбит/с. Объединение всех четырёх линий даёт суммарную скорость 100 Гбит/с.
|
||||
|
||||
> **Примечание:** management-интерфейс работает **только** на скорости 1 Гбит/с Ethernet. Скорости 10 и 100 Мбит/с не поддерживаются.
|
||||
|
||||
## 20.3. Гидры (breakout): один QSFP28 → четыре SFP+ (10G)
|
||||
|
||||
Для подключения 10-гигабитных интерфейсов используются **гидры** (breakout-кабели) — разветвители, преобразующие один порт QSFP28 в четыре порта SFP+ (10G):
|
||||
|
||||
```text
|
||||
QSFP28 порт (100G)
|
||||
│
|
||||
┌────┴────┐
|
||||
│ Гидра │
|
||||
└──┬─┬─┬─┬┘
|
||||
│ │ │ │
|
||||
SFP+ SFP+ SFP+ SFP+
|
||||
10G 10G 10G 10G
|
||||
```
|
||||
|
||||
Гидры могут быть:
|
||||
|
||||
- **Оптические** — с оптическими кабелями;
|
||||
- **DAC** (Direct Attach Copper) — с медными кабелями прямого подключения.
|
||||
|
||||
При использовании гидры в одном физическом QSFP28-разъёме появляется **до четырёх** независимых портов по 10 Гбит/с. Каждый из этих портов конфигурируется отдельно с указанием номера линии (lane).
|
||||
|
||||
## 20.4. Внутренняя архитектура
|
||||
|
||||
Внутренняя архитектура балансировщика включает несколько ключевых компонентов, связанных между собой:
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────┐
|
||||
│ Балансировщик │
|
||||
│ │
|
||||
│ ┌──────────┐ PCI-E ┌──────────────────┐ │
|
||||
│ │Микросервер├──────────────►│ Чип Barefoot │ │
|
||||
│ │ (Intel, │ │ Tofino │ │
|
||||
│ │ Linux) │ │ (коммутация) │──── 32× QSFP28
|
||||
│ └─────┬─────┘ └──────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌─────┴─────┐ ┌───────────┐ │
|
||||
│ │ Ethernet │ │ │ │
|
||||
│ │ switch ├─────┤ BMC │ │
|
||||
│ │ (5 портов) │ │ │ │
|
||||
│ └─────┬─────┘ └───────────┘ │
|
||||
│ │ │
|
||||
│ ┌─────┴─────┐ ┌───────────┐ │
|
||||
│ │ Management │ │Console MUX│ │
|
||||
│ │ Ethernet │ │ │ │
|
||||
│ └───────────┘ └───────────┘ │
|
||||
│ │ │
|
||||
│ ┌────┴────┐ │
|
||||
│ │ Console │ │
|
||||
│ └─────────┘ │
|
||||
└──────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 20.4.1. Микросервер (Intel, Linux) — CLI, конфигурация
|
||||
|
||||
**Микросервер** — основной «мозг» балансировщика, с которым взаимодействует оператор:
|
||||
|
||||
- Небольшая специализированная плата с **процессором Intel**;
|
||||
- Оснащён **памятью** и **SSD-диском** для хранения конфигурации и прошивки;
|
||||
- Работает под управлением **ОС Linux**;
|
||||
- Предоставляет **CLI** для настройки и мониторинга;
|
||||
- Связан с чипом Tofino по шине **PCI Express**;
|
||||
- **Программирует** чип Tofino — задаёт правила обработки и коммутации трафика.
|
||||
|
||||
Микросервер не обрабатывает трафик напрямую — он только управляет чипом коммутации.
|
||||
|
||||
### 20.4.2. Чип Barefoot Tofino — программируемая коммутация
|
||||
|
||||
**Barefoot Tofino** — высокопроизводительный программируемый чип, обеспечивающий коммутацию трафика на скорости провода:
|
||||
|
||||
- Соединён со всеми **32 портами QSFP28**;
|
||||
- Содержит **конвейеры** (pipelines), через которые проходят пакеты;
|
||||
- Программируется микросервером — правила балансировки, фильтрации, bypass загружаются в чип;
|
||||
- Обеспечивает производительность **3,2 Тбит/с**.
|
||||
|
||||
Все операции с трафиком (балансировка между фильтрами, программный байпас, фильтрация по flow rules) выполняются **внутри чипа Tofino** без участия микросервера.
|
||||
|
||||
### 20.4.3. BMC — управление аппаратной частью, сенсоры, блоки питания
|
||||
|
||||
**BMC** (Baseboard Management Controller) — модуль управления аппаратной платформой:
|
||||
|
||||
- **Мониторинг сенсоров** — температура, напряжение, токи;
|
||||
- **Управление блоками питания** — статус, параметры;
|
||||
- **Мониторинг SFP-трансиверов** — диагностическая информация, уровни сигналов (DDM);
|
||||
- **Аварийное управление** — при критических проблемах (например, перегрев) BMC может отключить отдельные компоненты или полностью погасить платформу.
|
||||
|
||||
> **Практический случай:** весной на ряде площадок наблюдались зависания балансировщиков. Причиной оказалось некорректное считывание BMC показаний температурного датчика — BMC ошибочно определял перегрев и выключал микросервер.
|
||||
|
||||
Доступ к BMC возможен:
|
||||
|
||||
- Через **внешнюю консоль** (при определённых настройках Console MUX);
|
||||
- Через **Management Ethernet** (один порт обеспечивает доступ и к микросерверу, и к BMC).
|
||||
|
||||
### 20.4.4. Ethernet switch (5-портовый) — доступ к микросерверу и BMC
|
||||
|
||||
Внутри балансировщика расположен **5-портовый Ethernet-коммутатор**, к которому подключены:
|
||||
|
||||
- **Management Ethernet** (внешний порт на передней панели);
|
||||
- **Микросервер** (CLI, конфигурация);
|
||||
- **BMC** (управление аппаратной частью).
|
||||
|
||||
Благодаря этому коммутатору **один внешний Ethernet-порт** обеспечивает доступ одновременно к микросерверу и BMC — каждый на своём IP-адресе.
|
||||
|
||||
### 20.4.5. Console MUX — переключение консоли между компонентами
|
||||
|
||||
**Console MUX** — мультиплексор консольного порта, позволяющий переключать физическую консоль между различными внутренними компонентами:
|
||||
|
||||
- **Микросервер** — основной режим, доступ к CLI;
|
||||
- **BMC** — для диагностики и восстановления аппаратной части.
|
||||
|
||||
> **Внимание:** скорость консольного порта может различаться в зависимости от того, к какому компоненту вы подключены. Если подключение к BMC — может быть одна скорость, к микросерверу — другая. На новых устройствах иногда приходится **подбирать скорость** консольного соединения.
|
||||
|
||||
## 20.5. Передняя панель: Console, Management Ethernet, USB
|
||||
|
||||
На передней панели балансировщика расположены:
|
||||
|
||||
| Порт / разъём | Описание |
|
||||
| ----------------------- | --------------------------------------------------------- |
|
||||
| **Console** | Консольный порт (через Console MUX переключается между микросервером и BMC) |
|
||||
| **Management Ethernet** | Порт управления (1 Гбит/с), доступ к микросерверу и BMC через внутренний коммутатор |
|
||||
| **USB** | USB-порт, доступен с микросервера и через USB-хаб |
|
||||
| **32× QSFP28** | Порты для подключения трафика (операторские линки и фильтры) |
|
||||
|
||||
Также на панели присутствует **диагностический разъём**, не используемый в эксплуатации.
|
||||
|
||||
**Учётные данные по умолчанию:**
|
||||
|
||||
| Доступ | Логин/пароль |
|
||||
| ---------- | ----------------------- |
|
||||
| **SSH** | `admin` / `admin` |
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 19: Фильтр: обновление прошивки](19.md) · [Раздел 21: Балансировщик: конфигурация →](21.md)
|
||||
486
21.md
Normal file
486
21.md
Normal file
@@ -0,0 +1,486 @@
|
||||
# 21. Балансировщик: конфигурация
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md)
|
||||
|
||||
---
|
||||
|
||||
Настройка балансировщика (EcoFilter Balancer) начинается после установки прошивки и конфигурации сегмента управления. В отличие от фильтра, на балансировщике **нет дефолтной конфигурации** — все секции (порты, линки, группы балансировки, фильтры) необходимо создавать вручную.
|
||||
|
||||
## 21.1. CLI: операционный режим / конфигурационный режим (`edit`)
|
||||
|
||||
CLI балансировщика, как и у фильтра, имеет **два режима** работы:
|
||||
|
||||
| Режим | Переход | Назначение |
|
||||
| -------------------- | -------------------- | ----------------------------------------- |
|
||||
| **Операционный** | по умолчанию | Просмотр информации: команды `show` |
|
||||
| **Конфигурационный** | команда **`edit`** | Изменение всех настроек устройства |
|
||||
|
||||
> **Отличие от фильтра:** на фильтре для перехода в конфигурационный режим используется команда `config`, а на балансировщике — **`edit`**.
|
||||
|
||||
### 21.1.1. Интерфейс похож на Juniper CLI
|
||||
|
||||
Интерфейс командной строки балансировщика **очень похож на CLI Juniper**. Настройки задаются с помощью команды `set`:
|
||||
|
||||
```text
|
||||
set <путь> <параметр> <значение>
|
||||
```
|
||||
|
||||
Для тех, кто знаком с оборудованием Juniper, работа с CLI балансировщика не вызовет затруднений.
|
||||
|
||||
### 21.1.2. `apply` — применить, `save` — сохранить в startup
|
||||
|
||||
После внесения изменений их необходимо применить и сохранить:
|
||||
|
||||
```text
|
||||
Внесение изменений ──► apply ──► save
|
||||
│ │ │
|
||||
│ │ └─ Сохранение в startup-config
|
||||
│ │ (переживёт перезагрузку)
|
||||
│ │
|
||||
│ └─ Применение конфигурации
|
||||
│ (изменения вступают в силу)
|
||||
│
|
||||
└─ Изменения только в буфере
|
||||
(не активны, не сохранены)
|
||||
```
|
||||
|
||||
| Команда | Действие |
|
||||
| ----------- | ------------------------------------------------------------------------- |
|
||||
| **`apply`** | Применяет конфигурацию — изменения вступают в силу |
|
||||
| **`save`** | Сохраняет конфигурацию в startup-config (переживёт перезагрузку) |
|
||||
|
||||
> **Важно:** в прошивке пилотного проекта (Урал) команда `apply` одновременно и применяла, и сохраняла конфигурацию в startup-config. В текущих (федеральных) прошивках это поведение изменено: `apply` только применяет, а для сохранения нужна отдельная команда `save`.
|
||||
|
||||
## 21.2. Обновление прошивки: `call rdp firmware download` / `call rdp install`
|
||||
|
||||
Обновление прошивки балансировщика выполняется в **два этапа** — скачивание и установка:
|
||||
|
||||
### Этап 1: Скачивание
|
||||
|
||||
```text
|
||||
call rdp firmware download <URL> <имя_файла>
|
||||
```
|
||||
|
||||
Скачивает образ прошивки с указанного URL и сохраняет его на устройстве под указанным именем.
|
||||
|
||||
### Этап 2: Установка
|
||||
|
||||
```text
|
||||
call rdp install <имя_файла>
|
||||
```
|
||||
|
||||
Устанавливает прошивку из указанного файла. По завершении команда выводит результат — `OK` или сообщение об ошибке.
|
||||
|
||||
### Дополнительные команды
|
||||
|
||||
| Команда | Действие |
|
||||
| -------------------------------- | ------------------------------------------------------ |
|
||||
| `call rdp firmware list` | Показать список файлов прошивок на устройстве |
|
||||
| `call rdp firmware delete` | Удалить файл прошивки |
|
||||
| `call rdp firmware set-active` | Установить активную прошивку на указанный раздел |
|
||||
| `show rdp firmware version` | Показать состояние прошивок (версия, активность, tries) |
|
||||
|
||||
### 21.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин)
|
||||
|
||||
Как и на фильтре, балансировщик хранит **два раздела** прошивок — **A** и **B**:
|
||||
|
||||
| Раздел | Описание |
|
||||
| ------ | ---------------------------------------------------------- |
|
||||
| **A** | Первый раздел для прошивки |
|
||||
| **B** | Второй раздел для прошивки |
|
||||
|
||||
Для каждого раздела отображается:
|
||||
|
||||
- **Активность** — активна эта прошивка или нет;
|
||||
- **Версия** — номер версии прошивки;
|
||||
- **Tries** — счётчик попыток загрузки.
|
||||
|
||||
Новая прошивка всегда устанавливается **вместо неактивной** в данный момент.
|
||||
|
||||
**Механизм автоматического rollback:**
|
||||
|
||||
Балансировщик отслеживает **количество неудачных попыток** загрузки с конкретной прошивки. Если устройство **более 3 раз подряд** не смогло загрузиться с определённой прошивки в течение приблизительно **20 минут**, эта прошивка считается **ненадёжной**, и балансировщик автоматически переключается на другой раздел.
|
||||
|
||||
> **Практический совет:** если вам нужно несколько раз перезагрузить балансировщик в короткий промежуток времени (например, для тестирования), помните о лимите в 3 перезагрузки. После третьей перезагрузки за короткий период прошивка будет признана нестабильной. Количество попыток и временной интервал **не настраиваются** — они зашиты в прошивке.
|
||||
|
||||
### 21.2.2. `call rdp firmware reset-tries`
|
||||
|
||||
Для сброса счётчика попыток загрузки используется команда:
|
||||
|
||||
```text
|
||||
call rdp firmware reset-tries
|
||||
```
|
||||
|
||||
Эта команда обнуляет значение **tries**, позволяя продолжить перезагрузки без риска автоматического переключения на другой раздел. В промышленной эксплуатации эта команда практически не требуется, но знать о ней полезно.
|
||||
|
||||
## 21.3. Настройка физических портов
|
||||
|
||||
Настройка физических портов — это **первый шаг** конфигурации балансировщика. Поскольку дефолтной конфигурации нет, все порты необходимо создавать вручную.
|
||||
|
||||
Для каждого порта задаются следующие параметры:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------- | ------------------------------------------------------------ |
|
||||
| **Имя порта** | Произвольное имя (рекомендуется формат `P<порт><линия>`) |
|
||||
| **number** | Номер физического интерфейса на лицевой панели (1–32) |
|
||||
| **lane** | Номер линии внутри физического порта (0–3) |
|
||||
| **speed** | Скорость порта: 10G, 25G или 100G |
|
||||
| **mtu** | Максимальный размер кадра |
|
||||
| **description** | Текстовое описание порта |
|
||||
|
||||
Пример конфигурации двух 10-гигабитных портов на одном физическом интерфейсе:
|
||||
|
||||
```text
|
||||
set ports P21 number 2 lane 1 speed 10g
|
||||
set ports P22 number 2 lane 2 speed 10g
|
||||
```
|
||||
|
||||
### 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed)
|
||||
|
||||
Имя порта может быть **произвольным**, однако рекомендуется придерживаться единообразной схемы именования, отражающей номер физического порта и номер линии:
|
||||
|
||||
```text
|
||||
P<номер_порта><номер_линии>
|
||||
```
|
||||
|
||||
Например:
|
||||
|
||||
| Имя порта | Физический порт | Линия | Скорость | Описание |
|
||||
| --------- | --------------- | ----- | -------- | ------------------------------------ |
|
||||
| `P21` | 2 | 1 | 10G | Порт 2, линия 1 — первый 10G-канал |
|
||||
| `P22` | 2 | 2 | 10G | Порт 2, линия 2 — второй 10G-канал |
|
||||
| `P2` | 2 | — | 100G | Порт 2, все линии — 100G-канал |
|
||||
|
||||
### 21.3.2. 10G: указание lane (0–3), 100G: все lane задействованы
|
||||
|
||||
Поведение параметра **lane** зависит от выбранной скорости:
|
||||
|
||||
**При 10G (или 25G):**
|
||||
|
||||
Каждый физический порт QSFP28 содержит 4 линии. При использовании гидры (breakout-кабеля) каждая линия становится отдельным 10-гигабитным портом. Для каждого такого порта необходимо явно указать номер линии (`lane 0`, `lane 1`, `lane 2`, `lane 3`):
|
||||
|
||||
```text
|
||||
set ports P20 number 2 lane 0 speed 10g
|
||||
set ports P21 number 2 lane 1 speed 10g
|
||||
set ports P22 number 2 lane 2 speed 10g
|
||||
set ports P23 number 2 lane 3 speed 10g
|
||||
```
|
||||
|
||||
В результате из одного физического QSFP28-разъёма получается **4 независимых порта** по 10 Гбит/с.
|
||||
|
||||
**При 100G:**
|
||||
|
||||
Все 4 линии объединены в один канал. Параметр `lane` **не указывается**, так как задействованы все линии:
|
||||
|
||||
```text
|
||||
set ports P2 number 2 speed 100g
|
||||
```
|
||||
|
||||
> **Рекомендация:** все физические порты настраиваются в соответствии со схемой организации связи на конкретной площадке. Единых «стандартных» настроек нет — конфигурация полностью зависит от того, какие устройства и на каких скоростях подключены к балансировщику.
|
||||
|
||||
## 21.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора)
|
||||
|
||||
**Линк** (link) в терминологии балансировщика — это объединение **двух портов** (LAN и WAN) в сторону оператора связи:
|
||||
|
||||
```text
|
||||
Оператор связи
|
||||
│
|
||||
┌────┴────┐
|
||||
│ Байпас │
|
||||
└──┬───┬──┘
|
||||
│ │
|
||||
LAN WAN ← это один линк
|
||||
│ │
|
||||
┌──┴───┴──┐
|
||||
│Балансир.│
|
||||
└─────────┘
|
||||
```
|
||||
|
||||
Каждый линк всегда содержит **ровно один LAN-порт** и **ровно один WAN-порт**.
|
||||
|
||||
Настройка линка:
|
||||
|
||||
```text
|
||||
set links <имя_линка> lan-port <имя_LAN_порта> wan-port <имя_WAN_порта>
|
||||
set links <имя_линка> description "<описание>"
|
||||
```
|
||||
|
||||
Пример:
|
||||
|
||||
```text
|
||||
set links link1 lan-port P21 wan-port P22
|
||||
set links link1 description "Bypass1-Mon0/Mon1"
|
||||
```
|
||||
|
||||
| Параметр | Описание |
|
||||
| ---------------- | ----------------------------------------------------------- |
|
||||
| **Имя линка** | Произвольное название (рекомендуется единообразная схема) |
|
||||
| **lan-port** | Порт в сторону абонентов (LAN) |
|
||||
| **wan-port** | Порт в сторону интернета (WAN) |
|
||||
| **description** | Описание — к какому байпасу и интерфейсу подключен линк |
|
||||
|
||||
> **Рекомендация:** в описании линка указывайте, к какому конкретно байпасу и к каким его интерфейсам подключён данный линк. Это значительно упрощает диагностику.
|
||||
|
||||
## 21.5. Настройка группы балансировки
|
||||
|
||||
После настройки портов и линков необходимо создать **группу балансировки** (balance group) и привязать к ней группы портов в сторону фильтров.
|
||||
|
||||
```text
|
||||
Линки (оператор) Группа балансировки Фильтры
|
||||
│ │ │
|
||||
┌────┴────┐ ┌──────┴──────┐ ┌─────┴─────┐
|
||||
│ link1 │ │ │ │ Filter │
|
||||
│ link2 │──────► │ Balance │──────│ Group 1 │──► Фильтр 1
|
||||
│ link3 │ Flow │ Group │ │ Group 2 │──► Фильтр 1
|
||||
│ ... │ rules │ │ │ Group 3 │──► Фильтр 2
|
||||
└─────────┘ └──────┬──────┘ │ ... │
|
||||
│ └───────────┘
|
||||
Профиль проверки
|
||||
доступности
|
||||
```
|
||||
|
||||
### 21.5.1. Привязка групп портов в сторону фильтров (filter groups)
|
||||
|
||||
К группе балансировки привязываются **filter groups** — пары портов (LAN + WAN) в сторону фильтров:
|
||||
|
||||
```text
|
||||
set balance-group <имя_группы> filter-group <имя_filter_group> lan-port <порт> wan-port <порт>
|
||||
```
|
||||
|
||||
Количество filter groups определяется количеством пар интерфейсов в сторону фильтров:
|
||||
|
||||
| Конфигурация площадки | Количество filter groups |
|
||||
| -------------------------------------------- | ------------------------ |
|
||||
| 1 фильтр, 16 портов (8 пар LAN/WAN) | 8 |
|
||||
| 10 фильтров, 16 портов каждый (80 пар) | 80 |
|
||||
|
||||
Каждая filter group объединяет один LAN-порт и один WAN-порт, смотрящие в сторону конкретной пары интерфейсов фильтра.
|
||||
|
||||
### 21.5.2. N_UNIT_QA: количество ядер фильтра минус один
|
||||
|
||||
Параметр **N_UNIT_QA** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика:
|
||||
|
||||
```text
|
||||
set balance-group <имя_группы> n-unit-qa <число>
|
||||
```
|
||||
|
||||
Значение **всегда равно общему количеству ядер процессора фильтра минус один**:
|
||||
|
||||
| Модель фильтра | Ядер всего | N_UNIT_QA |
|
||||
| ----------------------------- | ---------- | --------- |
|
||||
| Xeon 2695 (18 ядер) | 18 | 17 |
|
||||
| Xeon 2699 (22 ядра) | 22 | 21 |
|
||||
| Xeon Gold 6212 (24 ядра) | 24 | 23 |
|
||||
|
||||
Причина вычитания единицы: на фильтре **все ядра, кроме одного**, отданы под процесс EcoNAT, который обрабатывает трафик. Одно ядро — **сервисное**: на нём работает Linux, системные логи, управление. Оно не участвует в обработке трафика.
|
||||
|
||||
Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку.
|
||||
|
||||
## 21.6. Профиль проверки доступности (keep-alive)
|
||||
|
||||
К группе балансировки привязывается **профиль проверки доступности** (availability profile), определяющий параметры отправки keep-alive пакетов через группы портов в сторону фильтров.
|
||||
|
||||
```text
|
||||
set balance-group <имя_группы> availability-profile <имя_профиля>
|
||||
```
|
||||
|
||||
Профиль настраивается отдельно:
|
||||
|
||||
```text
|
||||
set availability-profile <имя_профиля> <параметр> <значение>
|
||||
```
|
||||
|
||||
### 21.6.1. Начальная задержка, интервал, порог потерь
|
||||
|
||||
| Параметр | Описание |
|
||||
| -------------------------- | -------------------------------------------------------------------- |
|
||||
| **Начальная задержка** | Время ожидания перед началом отправки keep-alive после поднятия интерфейсов (например, 1000 мс). Необходимо, чтобы фильтр успел полностью инициализировать интерфейсы |
|
||||
| **Интервал** | Периодичность отправки keep-alive пакетов (например, 100 мс) |
|
||||
| **Порог потерь (down)** | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5 пакетов) |
|
||||
| **Порог восстановления (up)** | Количество последовательно полученных ответов, после которых неактивная filter group считается снова **активной** |
|
||||
|
||||
Механизм работы: балансировщик отправляет keep-alive пакет в LAN-порт filter group и ожидает получить его через парный WAN-порт. Время прохождения пакета (time of pass) измеряется в наносекундах и в нормальном состоянии составляет порядка **20–30 микросекунд**.
|
||||
|
||||
При потере заданного количества последовательных пакетов filter group переводится в состояние **bypass** — трафик не отправляется на фильтр, а перекладывается из одного порта в другой на уровне логики балансировщика.
|
||||
|
||||
### 21.6.2. Минимальное количество активных пар
|
||||
|
||||
Параметр **минимальное количество активных пар** (minimum active pairs) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной.
|
||||
|
||||
Пример: если задано значение 8, то группа балансировки будет считаться рабочей, пока хотя бы 8 filter groups активны — неважно, сколько их всего.
|
||||
|
||||
> **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, и балансировщик включал bypass на всех линках. Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко.
|
||||
|
||||
### 21.6.3. Перебалансировка: включение/выключение
|
||||
|
||||
Параметр **перебалансировки** (rebalancing) определяет, что происходит при выходе из строя одной из filter groups:
|
||||
|
||||
| Значение | Поведение |
|
||||
| --------------- | ---------------------------------------------------------------------- |
|
||||
| **Включена** | Трафик пересчитывается и распределяется по оставшимся filter groups |
|
||||
| **Выключена** | Для упавшей filter group включается программный bypass, остальные работают без изменений |
|
||||
|
||||
**Перебалансировка** занимает определённое время и вычислительные ресурсы. При пересчёте хэша сессии могут попасть на **другие интерфейсы и другие фильтры**, что в общем случае может быть нежелательным (разрыв DPI-сессий, потеря контекста анализа).
|
||||
|
||||
> **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или разрыв всех сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную.
|
||||
|
||||
## 21.7. Настройка фильтров (Flow rules)
|
||||
|
||||
**Фильтры** (flow rules) на балансировщике — это правила, определяющие, что делать с трафиком, поступающим через линки. Каждое правило состоит из двух частей:
|
||||
|
||||
| Часть | Описание |
|
||||
| ---------- | ----------------------------------------------------------- |
|
||||
| **Match** | Условия, по которым отбирается трафик (заголовки пакетов) |
|
||||
| **Action** | Действие с пакетом при совпадении |
|
||||
|
||||
### 21.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов
|
||||
|
||||
Доступные условия для match-секции:
|
||||
|
||||
| Условие | Описание |
|
||||
| ---------------------- | ------------------------------------------------- |
|
||||
| **VLAN ID** | Номер VLAN-тега (например, `vlan 0 id 1`) |
|
||||
| **IPv4 source** | IP-адрес источника (с маской / префиксом) |
|
||||
| **IPv4 destination** | IP-адрес назначения (с маской / префиксом) |
|
||||
| **L4 port** | Порт транспортного уровня (TCP/UDP) |
|
||||
| **MAC address** | MAC-адрес источника или назначения |
|
||||
| **MPLS labels** | Количество MPLS-меток |
|
||||
| **Глубина VLAN-тегов** | Количество VLAN-тегов (для QinQ) |
|
||||
|
||||
В одном правиле можно комбинировать **несколько условий** одновременно. Например, одновременно проверять VLAN ID и IPv4-подсеть.
|
||||
|
||||
Match-условия можно использовать как для **включения** трафика в обработку, так и для **исключения** определённого трафика.
|
||||
|
||||
### 21.7.2. Actions: `balancing s_mac` → balance group / `bypass`
|
||||
|
||||
Действие (action) определяет, что происходит с пакетом при совпадении:
|
||||
|
||||
| Action | Описание |
|
||||
| ----------------------- | ---------------------------------------------------------------- |
|
||||
| **balancing s_mac** | Отправить трафик на группу балансировки. Балансировка выполняется по хэшу от source IP, destination IP и протокола |
|
||||
| **bypass** | Пропустить трафик прозрачно — переложить из одного порта в другой, не отправляя на фильтры |
|
||||
|
||||
При использовании `balancing s_mac` дополнительно указывается **целевая группа балансировки**:
|
||||
|
||||
```text
|
||||
set filters <имя_фильтра> flows <имя_правила> action balancing s_mac
|
||||
set filters <имя_фильтра> flows <имя_правила> to-balance-group <имя_группы>
|
||||
```
|
||||
|
||||
Пример правила, отправляющего трафик с VLAN ID 1 на фильтры:
|
||||
|
||||
```text
|
||||
set filters main flows traffic-to-filter-1 match vlan 0 id 1
|
||||
set filters main flows traffic-to-filter-1 action balancing s_mac
|
||||
set filters main flows traffic-to-filter-1 to-balance-group group-filter
|
||||
set filters main flows traffic-to-filter-1 priority 100
|
||||
```
|
||||
|
||||
Пример правила bypass для всего остального трафика:
|
||||
|
||||
```text
|
||||
set filters main flows default-bypass action bypass
|
||||
set filters main flows default-bypass priority 1
|
||||
```
|
||||
|
||||
### 21.7.3. Приоритеты правил
|
||||
|
||||
Каждому правилу назначается **приоритет** (priority), определяющий порядок обработки. Пакет проверяется по правилам в порядке убывания приоритета — от **высшего** к **низшему**. Первое совпавшее правило определяет действие.
|
||||
|
||||
Типовая структура правил:
|
||||
|
||||
```text
|
||||
Приоритет Правило Action
|
||||
─────────────────────────────────────────────────────
|
||||
100 VLAN 1 → на фильтр balancing s_mac
|
||||
90 VLAN 2 → на фильтр balancing s_mac
|
||||
80 VLAN 3 → на фильтр balancing s_mac
|
||||
... ... ...
|
||||
1 Всё остальное → bypass bypass
|
||||
```
|
||||
|
||||
Правило с **самым низким приоритетом** и **без match-условий** (совпадает со всем) обычно задаёт action `bypass`. Это означает: всё, что не попало под предыдущие правила, пропускается прозрачно.
|
||||
|
||||
> **Применение для диагностики:** при траблшутинге можно создать правило с высоким приоритетом, которое перехватывает трафик конкретного VLAN и выполняет action `bypass`. Это позволяет исключить конкретный трафик из обработки фильтрами и проверить, влияет ли ТСПУ на проблему. По статистике правила (количество пакетов/байт) можно убедиться, что трафик действительно проходит через это правило.
|
||||
|
||||
### 21.7.4. Привязка фильтров к линкам
|
||||
|
||||
После настройки правил необходимо **привязать фильтр к линкам** — указать, на каких линках (в сторону оператора) данные правила будут действовать:
|
||||
|
||||
```text
|
||||
set filters <имя_фильтра> links [ <линк1> <линк2> ... ]
|
||||
```
|
||||
|
||||
Пример:
|
||||
|
||||
```text
|
||||
set filters main links [ link1 link2 link3 link4 ]
|
||||
```
|
||||
|
||||
Один набор правил (фильтр) может быть привязан к **нескольким линкам** одновременно. Все линки, привязанные к фильтру, используют одни и те же flow rules.
|
||||
|
||||
## 21.8. Настройка Heartbeat для GL Sun (пилотный проект)
|
||||
|
||||
Данная настройка актуальна **только для пилотного проекта на Урале**, где используются байпасы GL Sun. В федеральном проекте с байпасами Silicom эта настройка **не требуется** — Silicom самостоятельно генерирует и проверяет heartbeat-пакеты.
|
||||
|
||||
На Урале балансировщик работает в активном режиме и сам должен отправлять heartbeat-пакеты на байпас GL Sun:
|
||||
|
||||
| Параметр | Описание |
|
||||
| --------------------------- | --------------------------------------------------------------- |
|
||||
| **IPv4-адрес байпаса** | IP-адрес байпаса GL Sun |
|
||||
| **Порт** | Порт для heartbeat-протокола |
|
||||
| **Период отсылки** | Интервал отправки heartbeat (в наносекундах, например, 30 мкс) |
|
||||
| **Группа балансировки** | Группа, для которой работает отправка heartbeat |
|
||||
| **Список линков байпаса** | Идентификаторы сущностей на стороне байпаса GL Sun |
|
||||
| **ToS** | Тип сервиса в IP-заголовке heartbeat-пакетов |
|
||||
| **Автоматический возврат** | Возможность автоматического возврата трафика в режим primary при восстановлении группы балансировки |
|
||||
|
||||
Heartbeat-пакеты отправляются только при условии, что **группа балансировки находится в состоянии Active**. При переходе группы в неактивное состояние отправка прекращается, и связь с байпасом (по TCP) разрывается — состояние переходит в `disconnected`.
|
||||
|
||||
> **Примечание:** с байпасами Silicom логика работы другая — Silicom самостоятельно отсылает heartbeat и проверяет доступность интерфейсов, а балансировщик прозрачно пропускает эти пакеты между своими портами.
|
||||
|
||||
## 21.9. Management-интерфейс: IP, маска, default gateway
|
||||
|
||||
Настройка management-интерфейса балансировщика выполняется аналогично другим сетевым устройствам:
|
||||
|
||||
```text
|
||||
set management ip <IP-адрес>
|
||||
set management mask <маска_подсети>
|
||||
set management default-gateway <IP-шлюза>
|
||||
```
|
||||
|
||||
Management-интерфейс обеспечивает доступ к устройству по SSH и используется для управления, мониторинга и взаимодействия с ЦСУ.
|
||||
|
||||
> **Напоминание:** management Ethernet работает **только** на скорости 1 Гбит/с (см. [раздел 20.2](20.md)).
|
||||
|
||||
---
|
||||
|
||||
## Общий порядок настройки балансировщика
|
||||
|
||||
Для наглядности — последовательность настройки балансировщика «с нуля»:
|
||||
|
||||
```text
|
||||
1. Установить прошивку
|
||||
│
|
||||
2. Настроить management-интерфейс
|
||||
│
|
||||
3. Настроить физические порты (ports)
|
||||
│
|
||||
4. Настроить линки (links) — пары LAN/WAN в сторону оператора
|
||||
│
|
||||
5. Настроить группу балансировки (balance group)
|
||||
└── Создать filter groups (пары портов в сторону фильтров)
|
||||
└── Задать N_UNIT_QA
|
||||
└── Привязать профиль проверки доступности
|
||||
│
|
||||
6. Настроить профиль проверки доступности (availability profile)
|
||||
│
|
||||
7. Настроить фильтры (flow rules) — правила обработки трафика
|
||||
└── Привязать фильтры к линкам
|
||||
│
|
||||
8. apply + save
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
[← Оглавление](README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) · [Раздел 22: Балансировщик: мониторинг и диагностика →](22.md)
|
||||
24
README.md
24
README.md
@@ -114,14 +114,14 @@
|
||||
- 9.4. Подсистемы ЦСУ: формирование списков, мониторинг, логирование, картография
|
||||
- 9.5. Новая ЦСУ для федерального проекта (замена уральской)
|
||||
|
||||
### 10. Сегмент управления ТСПУ
|
||||
### [10. Сегмент управления ТСПУ](/10.md)
|
||||
|
||||
- 10.1. Адресация: 10.<регион>.<площадка>.0/24
|
||||
- 10.2. Распределение адресов: байпасы, балансировщики, BMC, фильтры, IPMI, SPFS, СПХД
|
||||
- 10.3. Шлюз по умолчанию — криптошлюз «Континент»
|
||||
- 10.4. Подсеть логирования (единая для всех ТСПУ)
|
||||
|
||||
### 11. Фильтр: аппаратная платформа
|
||||
### [11. Фильтр: аппаратная платформа](/11.md)
|
||||
|
||||
- 11.1. Младшая линейка: EcoFilter 2020/2040
|
||||
- 11.2. Старшая линейка: EcoFilter 4080/4120/4160
|
||||
@@ -134,7 +134,7 @@
|
||||
- 11.5. Разделение интерфейсов: LAN (чётные) / WAN (нечётные)
|
||||
- 11.6. История платформы: от CGNAT (2013) к DPI-фильтру
|
||||
|
||||
### 12. Сессии и трансляции на фильтре
|
||||
### [12. Сессии и трансляции на фильтре](/12.md)
|
||||
|
||||
- 12.1. Понятие сессии: local IP:port + global IP:port + remote IP:port
|
||||
- 12.2. Понятие трансляции: local IP:port ↔ global IP:port
|
||||
@@ -145,7 +145,7 @@
|
||||
- 12.7. Тайм-ауты сессий и трансляций
|
||||
- 12.8. Команды: `show session`, `show xl`, фильтрация по `local`/`remote`, pipe и count
|
||||
|
||||
### 13. Фильтр: первоначальная настройка и CLI
|
||||
### [13. Фильтр: первоначальная настройка и CLI](/13.md)
|
||||
|
||||
- 13.1. Подключение: консоль (115200 8N1) и SSH (порт 22)
|
||||
- 13.2. Логин по умолчанию: admin / econat
|
||||
@@ -159,7 +159,7 @@
|
||||
- 13.8. «Мышеловка» (trap mode) при незакрытой скобке
|
||||
- 13.9. Ключевое слово `ls` для быстрого просмотра
|
||||
|
||||
### 14. Фильтр: конфигурация подсистем
|
||||
### [14. Фильтр: конфигурация подсистем](/14.md)
|
||||
|
||||
- 14.1. Консольный порт: скорость, тайм-аут неактивности
|
||||
- 14.2. Management-интерфейс: IP, gateway, DNS, allowed IP
|
||||
@@ -181,7 +181,7 @@
|
||||
- 14.10.1. Выбор протоколов (all / конкретные)
|
||||
- 14.10.2. Количество пакетов на протокол (по умолчанию 30, рекомендуется 3)
|
||||
|
||||
### 15. Фильтр: настройка интерфейсов и общих параметров
|
||||
### [15. Фильтр: настройка интерфейсов и общих параметров](/15.md)
|
||||
|
||||
- 15.1. Интерфейсы: enable/disable, description (LACP не используется)
|
||||
- 15.2. NAT Defaults — общие параметры устройства
|
||||
@@ -194,7 +194,7 @@
|
||||
- 15.3. Тайм-ауты сессий и трансляций
|
||||
- 15.4. IPv6: включение, диапазон адресов для обработки
|
||||
|
||||
### 16. Фильтр: ACL и пулы — запуск трафика на обработку
|
||||
### [16. Фильтр: ACL и пулы — запуск трафика на обработку](/16.md)
|
||||
|
||||
- 16.1. Создание ACL: `create acl`, правила (allow/deny), протоколы, source/destination, VLAN
|
||||
- 16.2. Создание пула: `create pool`, тип = fake (без NAT)
|
||||
@@ -203,7 +203,7 @@
|
||||
- 16.5. Connection logging в пуле
|
||||
- 16.6. IPv6 в пуле
|
||||
|
||||
### 17. Фильтр: настройка DPI
|
||||
### [17. Фильтр: настройка DPI](/17.md)
|
||||
|
||||
- 17.1. Общие настройки модуля DPI
|
||||
- 17.1.1. Включение/выключение DPI
|
||||
@@ -235,7 +235,7 @@
|
||||
- 17.5.2. HTTP: блокировка конкретного URL
|
||||
- 17.5.3. HTTPS: блокировка только по домену (SNI/Client Hello)
|
||||
|
||||
### 18. Фильтр: мониторинг и диагностика
|
||||
### [18. Фильтр: мониторинг и диагностика](/18.md)
|
||||
|
||||
- 18.1. `show version` — версия ПО, серийный номер (= MAC management)
|
||||
- 18.2. `show ip if` — параметры management-интерфейса
|
||||
@@ -263,7 +263,7 @@
|
||||
- 18.13.5. `show dpi match <ресурс>` — проверка ресурса по всем DPI-листам
|
||||
- 18.14. Ping и Traceroute (из конфигурационного режима)
|
||||
|
||||
### 19. Фильтр: обновление прошивки
|
||||
### [19. Фильтр: обновление прошивки](/19.md)
|
||||
|
||||
- 19.1. Два раздела: prim1 и prim2 (равнозначные) + FB (заводская)
|
||||
- 19.2. `firmware status` — текущее состояние (cur / boot)
|
||||
@@ -271,7 +271,7 @@
|
||||
- 19.4. `firmware rollback` / `firmware reset`
|
||||
- 19.5. Централизованное обновление через ЦСУ
|
||||
|
||||
### 20. Балансировщик: аппаратная платформа
|
||||
### [20. Балансировщик: аппаратная платформа](/20.md)
|
||||
|
||||
- 20.1. Одноюнитовый (32 порта QSFP28) и двухюнитовый (65 портов)
|
||||
- 20.2. Скорости портов: 10G / 25G / 100G
|
||||
@@ -284,7 +284,7 @@
|
||||
- 20.4.5. Console MUX — переключение консоли между компонентами
|
||||
- 20.5. Передняя панель: Console, Management Ethernet, USB
|
||||
|
||||
### 21. Балансировщик: конфигурация
|
||||
### [21. Балансировщик: конфигурация](/21.md)
|
||||
|
||||
- 21.1. CLI: операционный режим / конфигурационный режим (`edit`)
|
||||
- 21.1.1. Интерфейс похож на Juniper CLI
|
||||
|
||||
Reference in New Issue
Block a user