MAC каждого члена пула больше не статическая константа в topology.env,
а резолвится демоном hcd через обычный ARP ядра — в реальном
окружении MAC бэкенда заранее не известен (сервер ещё не подключён,
NIC может замениться), топология не описывается статически, в отличие
от стенда.
hcif-порты (единственные адреса узла в ядре) уже были настоящими
L3-интерфейсами в тех же сегментах, что и бэкенды — единственное, что
мешало обычному ARP, это permanent-записи ip neigh в entrypoint.sh.
Убрав их и добавив hc/neigh.go (читает ip -json neigh show, точечно
заливает бандл в таблицу 21 на том же тикере, что и health-пробы),
получили резолвер без нового OpenFlow-контроллера.
Таблица 21 стала единственным источником MAC для обоих путей —
маршрутизируемого и коммутируемого (шаг 3): таблица 12 больше не
дублирует MAC инлайново, ct(commit) ведёт сразу в таблицу 21.
Исправлен попутно найденный баг: после apply.sh (replace-flows)
таблица 21 не восстанавливалась, поскольку syncNeighbors сравнивал
MAC с памятью демона, а не с датапасом. Добавлен force-режим по
аналогии с Agent.apply(), плюс регрессионная проверка в verify.sh.
Проверено на живом стенде: MAC всех четырёх членов резолвлен и
совпадает с реальными интерфейсами; смена MAC "железа" обнаружена и
применена без вмешательства за счёт штатного старения ARP ядра.
Регрессия: 94 из 94 проверок.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Зафиксирован разбор шага 4: осуществимость замены ct(commit,nat) /
ct(nat) на публичном пути статическими правилами DNAT/un-DNAT без
состояния, при сохранении требования "бэкенд видит реальный IP
клиента, клиент получает корректный ответ от VIP".
Ключевые находки:
- условие периметра — бэкенды не должны быть достижимы клиентами
напрямую, иначе ответ на прямой запрос неотличим от ответа на
сессию через VIP по заголовкам;
- связность be<->be между разными сегментами сохраняется правилом
nw_dst=$PUB_NET в un-DNAT; связность внутри одного сегмента (т.24,
шаг 3) требует отдельного решения и не входит в объём public-only
оценки;
- установленные сессии перестают быть защищены ct при смене состава
пула — принимаемый компромисс, ранее предсказанный в STEP2_SUMMARY;
- доставка до физического сервера по MAC в EVPN-фабрике — отдельный,
не связанный с conntrack вопрос модели adjacency (табл. 21).
Это оценка осуществимости, не план внедрения и не реализация.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Анализ текущего состояния и перечень изменений для классического
режима облачного балансировщика: несколько листенеров (публичных
и/или приватных), каждый со своим независимым пулом.
Подтверждено на стенде: сейчас все листенеры делят один POOL_ID и
одну таблицу слотов (reg1 -> reg2), member_id глобален. multipath
для разных листенеров с одним POOL_ID даёт одинаковый номер слота
для совпадающего 5-tuple — пулы физически не разделены.
Предложена схема reg4 = pool_id: таблица слотов становится общей
для всех пулов с матчем (reg4, reg1), FlowBundle.flow delete
фильтруется по reg4 для инкрементального обновления одного пула.
Замер: 1024 правила заливаются бандлом за 86 мс.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Анализ текущего состояния и перечень изменений для размещения 100+
тенантов на одной ноде с изоляцией уровня VRF.
Ключевая проблема — пересекающиеся адресные пространства тенантов:
ни один матч в пайплайне не может опираться на IP или MAC без
идентификатора тенанта. Предложена схема с tenant_id в reg3 и
ct-зоной из регистра (ct(zone=NXM_NX_REG3[0..15]) — синтаксис
проверен на стенде).
Отдельно оценён масштаб: таблица слотов доминирует (100 пулов по 1024
слота дают 102400 правил и ~8.8 с полной перезаливки при замеренных
88 мс на 1024 правила), поэтому SLOTS должен стать параметром пула,
а apply.sh — перейти на инкрементальные бандлы.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Анализ текущего состояния стенда и перечень изменений для ПРОД-окружения
на выделенном сервере с OVS-DPDK.
Основной вывод инвентаризации: вся форвардинг-логика DPDK-совместима,
pipeline.sh переносится без изменений. Переделке подлежат подключение
портов (macvlan и veth -> dpdk и vhost-user), размещение узла
(контейнер -> железо) и инструментарий.
Отдельно зафиксировано, что потолок производительности сместится с PPS
на CPS: multipath и ct(commit) дают upcall на каждое новое соединение,
и они же вместе с learn блокируют hardware offload.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ayurishchevandClaude Opus 5