docs/STEP5_SUMMARY.md

# Шаг 5 — итоги: динамическое изучение MAC/ARP для бэкендов

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

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

MAC каждого члена пула больше не статическая константа из `topology.env` — он
резолвится динамически демоном `hcd` через обычный ARP ядра.

- **`lb/entrypoint.sh`** — убраны permanent-записи `ip neigh` для адресов
  членов пула. `hcif-p2`/`hcif-p3` — настоящие L3-интерфейсы ядра в тех же
  сегментах, что и бэкенды, поэтому ядро само резолвит их MAC обычным ARP:
  первая health-проба порождает ARP-запрос через `br-lb`, реальный бэкенд
  отвечает, ядро запоминает.
- **`hc/neigh.go`** (новый) — на том же тикере, что и health-пробы, читает
  `ip -json neigh show` для каждого члена по его интерфейсу (`hcif-p2`/
  `hcif-p3`, новое поле `iface` в конфиге) и при изменении MAC атомарно
  заливает точечный бандл `ovs-ofctl bundle` в таблицу 21 — не трогая записи
  остальных членов.
- **Таблица 21 стала единственным источником MAC** для обоих путей —
  маршрутизируемого и коммутируемого (шаг 3). Таблица 12 (same-segment DNAT)
  больше не пишет MAC инлайново: `ct(commit,...)` теперь ведёт напрямую в
  таблицу 21 вместо таблицы 25, минуя таблицу 20 (TTL по-прежнему не
  уменьшается для соседей по сегменту).
- **`lbctl neigh` / `make neigh`** — таблица «член / адрес / интерфейс / MAC /
  резолвлен / с момента», плюс сырые правила таблицы 21.
- **`BE1_MAC`…`BE4_MAC` в `topology.env`** остались только как «заводской» MAC,
  который `attach-segment.sh` назначает интерфейсу ВМ (эмуляция того, что
  реально прошито в NIC) — в OpenFlow эти переменные больше не попадают.

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

| Проверка | Результат |
|---|---|
| `lbctl neigh` показывает реальный MAC каждого члена | совпадает с `ip link show eth0` внутри контейнера |
| Таблица 21, приоритет 100 | правило на каждого члена, `actions` содержат резолвленный MAC |
| Регрессия (все шаги 1–3) | 86 существующих проверок без изменений в поведении |
| **Смена MAC «железа»** | `ip link set eth0 address ...` у be1 → обнаружено `hcd`, таблица 21 обновлена, доставка восстановлена без вмешательства |
| Идемпотентность `apply.sh` | таблица 21 полностью восстанавливается после `replace-flows` (см. отклонения) |

## Ключевая находка (уже была на момент планирования)

`segment_ingress()`/`l3_learn()` и раньше заливала действием `learn` записи
приоритета 90 в таблицу 21 для любого IP-трафика с портов сегмента, включая
ответы бэкендов на health-пробы — но они были перекрыты статическими
правилами приоритета 100. Шаг 5 не строил резолвер с нуля: снял то, что
блокировало естественный ARP ядра (`nud permanent`), и сделал `hcd` явным,
наблюдаемым источником приоритета 100 вместо неявного поведения `learn`.
Разделение осталось ровно таким, как задумано: `learn` (приоритет 90)
по-прежнему единственный механизм для клиентов — их адрес заранее не известен
и не enumerable; `hcd` (приоритет 100) — для членов пула, чей адрес известен
из конфигурации.

## Отклонение от плана: баг с `force`

Первая реализация не заливала таблицу 21 заново после `apply.sh`
(`replace-flows` стирает весь пайплайн). Причина: `syncNeighbors()` сравнивал
резолвленный MAC с MAC **в памяти демона** — после `replace-flows` датапас
пуст, но в памяти MAC не изменился, поэтому условие «MAC изменился» не
срабатывало и точечный бандл не переливался. Обнаружено тестом идемпотентности
(`verify.sh`, блок 14 → новая проверка блока 17) — именно то, для чего этот
тест и существует.

Исправление зеркально `force` у `Agent.apply()`: `syncNeighbors(force bool)`,
`/reapply` теперь вызывает `a.syncNeighbors(true)` вслед за `a.apply(true)`.
Это тот же класс проблемы, что уже был явно предусмотрен для таблицы слотов
(`force заставляет залить даже неизменившуюся`, `hc/main.go`), просто
не был перенесён на новый подкомпонент при первой реализации.

## Наблюдение: реальная скорость обнаружения смены MAC

Проверка на живом стенде: смена MAC интерфейса `be1` обнаружена ядром и
отражена `hcd` в датапасе примерно через **2 минуты**, а не за один-два цикла
тикера (2 с), как можно было бы предположить из интервала опроса `hcd`.

Причина — `hcd` опрашивает **быстро** (каждые 2 с), но может отразить только
то, что уже узнало **ядро**, а стандартное старение Linux ARP (`REACHABLE` →
`STALE` → `DELAY` → `PROBE` → `FAILED`/переразрешение) по умолчанию рассчитано
на десятки секунд на первом же переходе (`base_reachable_time` ≈ 30 с) и суммарно
может занимать порядка минуты и больше. Частота опроса `hcd` не сокращает
это время — она лишь гарантирует, что новый MAC попадёт в датапас на первом же
тике **после** того, как его узнало ядро. Это честная характеристика решения,
а не дефект: тот же порядок величины, что и в реальных сетях с обычным ARP.

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

1. **`nud permanent` для members убраны полностью**, без опционального
   ручного `mac`-переопределения в JSON — как и намечалось («не делать этого
   на первой итерации»). Подтверждено достаточным: cold-start окно закрывается
   первой же успешной пробой.
2. **Обнаружен и исправлен баг с `force`**, не предусмотренный явно в плане
   (план предполагал его как риск в общих чертах — «зависимость от `ip -json
   neigh`», но не called out force-реапплай конкретно). Добавлена
   регрессионная проверка (`verify.sh`, блок 17) именно на этот случай.
3. **Проверка TTL в блоке 15 (`verify.sh`) сделана устойчивее**: захват `-c 4`
   на 12 запросах оказался статистически хрупким — при 4 членах пула 12
   запросов иногда не попадали ни разу на соседа по сегменту, тест ложно
   падал. Увеличено до `-c 16` на 32 запросах; на двух прогонах подряд
   стабильно зелёный. Не связано с шагом 5 по существу (тест существовал с
   шага 3), но исправлено в этой же сессии, раз затронут `verify.sh`.

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

- **Обнаружение новых, необъявленных хостов вне объёма** — резолвится MAC
  только для адресов, уже присутствующих в `hc-config.sh`. Обнаружение самих
  адресов — отдельная, более крупная задача control plane (`MULTITENANCY.md`).
- **Скорость обнаружения смены MAC ограничена стандартным старением ARP ядра**
  (см. наблюдение выше) — величина порядка минуты, не секунд.
- **Окно на холодном старте**: пока `hcd` не сделал первый резолв, трафик к
  члену зависит от того, успел ли сработать `learn` (приоритет 90); в худшем
  случае — `priority=0 drop`. По порядку величины совпадает с fail-close
  таблицы слотов, новой категории риска не вводит.
- **`ip -json neigh`** — версия `iproute2` в образе (`6.1.0`) поддерживает флаг;
  при смене базового образа стоит переподтвердить.

## Задел на следующие шаги

1. Тот же приём (демон резолвит адрес через ядро и заливает точечным бандлом)
   применим к обнаружению самих хостов, если понадобится снять ограничение
   «только уже известные адреса» — потребует ARP-сканирования сегмента и
   решения, как новый хост попадает в конфигурацию пула.
2. Control plane (`Load_Balancer → Listener → Pool → Member` в OVSDB,
   `MULTITENANCY.md`) естественно принимает поле `iface` как часть модели
   `Member`, а не специфику `hc-config.sh`.