docs/STEP3_SUMMARY.md

# Шаг 3 — итоги: листенер в приватном сегменте

**Дата:** 2026-08-17
**Статус:** выполнено, проверено после холодного перезапуска (86 из 86 проверок)
**План:** [STEP3_IMPLEMENTATION_PLAN.md](STEP3_IMPLEMENTATION_PLAN.md)
**Предыдущий шаг:** [STEP2_SUMMARY.md](STEP2_SUMMARY.md)

## Что сделано

Балансировщик получил листенеры в приватных сегментах — `10.20.0.100:80` и
`10.30.0.100:80` — и научился обслуживать клиента, который стоит **в одном
сегменте с бэкендами**. Исходный IP клиента сохраняется, порт транслируется
80 → 8080, в ОС виртуальных машин не настраивается ничего.

- **`br-lb` стал коммутатором приватного сегмента.** Каждая ВМ подключена
  отдельным портом (`scripts/attach-segment.sh`), порты `p2`/`p3` остались
  аплинками сегмента к шлюзу Docker. Появились таблицы 0 (сегментация и
  обучение), 25 (FDB, broadcast и unknown flood) и 1 (классификация).
- **Обратная трансляция коммутируемого трафика — таблица 24.** Ответ бэкенда
  клиенту-соседу уходит по L2 напрямую, но проходит через мост, где `ct(nat)`
  возвращает источник к `VIP:80`.
- **Выдача на члена своего сегмента — без маршрутизации.** Таблица 12 при
  совпадении сегмента клиента и члена меняет только MAC назначения и отдаёт кадр
  в коммутацию: `dec_ttl` не выполняется, клиент и бэкенд остаются L2-соседями.
- **Пул общий с публичным листенером** — та же таблица слотов, тот же `pool_id`,
  тот же дайджест `0a16713c5a9eb94d`. Демон `hcd` не изменён ни строкой.
- **Переключатель `PRIV_LISTENERS`** в `topology.env`: пусто — приватных
  листенеров нет, `"p2"` — один сегмент, `"p2 p3"` — оба.
- **Клиенты сегментов** `cli2` (`10.20.0.10`) и `cli3` (`10.30.0.10`) — ВМ без
  единого маршрута в таблице маршрутизации.

## Почему именно так

Клиент и бэкенд — L2-соседи, поэтому ответ бэкенда уходит клиенту напрямую.
Снять DNAT можно только там, где этот кадр виден. Остальные пути отпадали по
условиям задачи:

| Вариант | Почему отвергнут |
|---|---|
| SNAT | уничтожает сохранение IP клиента |
| DSR, VIP на `lo` бэкенда | требует настройки ОС ВМ, не транслирует порт |
| Изоляция портов сегмента | блокирует внутрисегментный трафик, неприменима к ВМ |
| Дробление подсети маршрутами `/25` | вмешательство в ОС ВМ и в адресацию заказчика |

Осталась единственная предпосылка, совпадающая с зоной влияния SDN: **порты ВМ
— порты OVS**. В целевой среде это выполняется по построению; стенд приведён к
той же модели.

## Результаты проверок

| Проверка | Результат |
|---|---|
| ВМ сегментов подключены портами OVS | 6 портов: be1, be3, cli2, be2, be4, cli3 |
| `ping 10.20.0.100` из `cli2` | отвечают ARP- и ICMP-респондеры OVS |
| Балансировка из приватного клиента | 24 запроса, задействованы все четыре члена |
| **IP клиента на бэкенде** | `client=10.20.0.10` во всех ответах |
| **Трансляция порта** | `served=10.20.0.2:8080` при листенере на 80 |
| Член в сегменте клиента | обслуживает запросы, ответ транслируется таблицей 24 |
| **TTL ответа от VIP** | 64 для членов своего сегмента, 63 — для членов другого |
| В ОС клиента нет маршрутов | `ip route` содержит только connected-запись |
| Внутрисегментная связность | `cli2 → be1` напрямую, `be1 → be3`, шлюз Docker — всё работает |
| Отказ члена под нагрузкой из `cli2` | слоты разошлись 341/342/341, 2 ошибки в окне обнаружения |
| Профиль A | egress бэкенда адресован шлюзу Docker, не маршрутизатору сегмента |
| `PRIV_LISTENERS="p2"` | листенер в priv3 выключен (счётчик drop растёт), связность цела |
| Регрессия шагов 1–2 | публичный листенер, транзит, health-check, fail-close, дренаж — без изменений |

## Главное измерение: TTL как признак пути

Ответы от `be1`/`be3` (сегмент клиента) приходят с **TTL 64**, от `be2`/`be4`
(другой сегмент) — с **TTL 63**. Это прямое доказательство того, что для соседей
по сегменту балансировщик не стал L3-хопом: он подменил MAC назначения,
оттранслировал адрес и отдал кадр коммутацией. С точки зрения ВМ ничего не
изменилось — она общается с соседом по подсети, как и раньше.

Для членов из другого сегмента работает прежний маршрутизируемый путь с
`dec_ttl`. Оба пути живут на одном пуле и одной таблице слотов, и клиент их не
различает.

## Отклонения от плана

1. **`load:0->NXM_OF_IN_PORT[]` не понадобился.** План предполагал hairpin —
   выдачу в порт входа — и сброс `in_port`, чтобы OVS не подавил вывод. После
   перевода каждой ВМ на собственный порт hairpin исчез: клиент и бэкенд входят
   и выходят через разные порты. Риск снят самой архитектурой.

2. **Отдельная сеть для egress не потребовалась.** План предусматривал служебную
   docker-сеть под default-маршрут. Оказалось достаточно оставить `p2`/`p3`
   аплинками сегмента: бэкенд адресует кадр MAC-у шлюза Docker, мост его
   коммутирует, и профиль A сохраняется в прежнем виде.

3. **Появилась таблица 1.** В плане классификация оставалась в таблице 0. Но
   таблица 0 занята определением сегмента и обучением (два действия `learn` на
   каждый порт), поэтому классификация вынесена отдельно — иначе правила
   пришлось бы дублировать на каждый порт сегмента.

4. **`make` больше не требует `sudo`.** Под root его в системе может не быть;
   цели подготовки хоста теперь подставляют `sudo` только при запуске не от root.

5. **Проверки 7 и 9 в `verify.sh` переформулированы.** Обе слушали аплинк `p2`,
   через который health-пробы и egress больше не проходят: пробы идут
   коммутацией на порт ВМ, а признаком профиля A стал MAC назначения (шлюз
   Docker, а не маршрутизатор сегмента), а не отсутствие трафика на `p2`.

## Известные ограничения

- **Предпосылка архитектуры:** порты ВМ должны быть портами OVS. Если между
  клиентом и бэкендом окажется коммутатор, который SDN не контролирует, кейс не
  решается ничем, кроме SNAT.
- **Хрупкость стенда:** veth, созданные `attach-segment.sh`, исчезают при
  пересоздании контейнера — нужен `make attach`. В целевой среде порты создаёт
  гипервизор.
- **Весь внутрисегментный трафик проходит через `br-lb`** — пропускная
  способность узла становится пропускной способностью сегмента. Замер k6 не
  выполнен: в системе нет клиента k6; цель для сравнения —
  `http://10.20.0.100/` против `http://192.168.5.21/`.
- **Обратная трансляция опирается на `ct`** — как и прежде. Stateless-вариант
  (`nw_src=member, tp_src=8080 → VIP:80`) остаётся заделом: в сегменте он
  потребует аккуратного исключения трафика, который бэкенд сам инициирует с
  порта 8080.
- **Unicast ARP внутри сегмента рассылается флудом**, если MAC ещё не выучен —
  обычное поведение обучающегося коммутатора, но без таймера старения записей
  короче 300 с.
- **Приватный листенер только TCP и только IPv4**, как и публичный. UDP- и
  L3-листенеров нет.
- Кворум, control plane в OVSDB, ICMP-ошибки и фрагменты — по-прежнему вне рамок.

## Задел на шаг 4

1. **Stateless-датапас** для обоих путей: явный un-DNAT вместо `ct(nat)`.
   На коммутируемом пути это снимет последнюю зависимость от состояния.
2. **Control plane:** модель `Load_Balancer → Listener → Pool → Member` в OVSDB
   вместо `topology.env`. Сейчас листенер, сегмент и состав пула описаны в трёх
   местах, а добавление ВМ требует правки `topology.env`, `hc-config.sh` и
   запуска `attach-segment.sh`.
3. **Старение FDB и защита от переполнения** — сейчас записи живут 300 с без
   ограничения на число MAC в сегменте.
4. Второй узел LB: кворум наблюдений, генерации пулов, сравнение дайджестов.