diff --git a/PROBLEM-AND-SOLUTION.md b/PROBLEM-AND-SOLUTION.md
index 00d27f6..a634c01 100644
--- a/PROBLEM-AND-SOLUTION.md
+++ b/PROBLEM-AND-SOLUTION.md
@@ -66,20 +66,62 @@ Underlay MTU = 1450 → Geneve-туннель = 1400 → поды = 1400.
 
 ---
 
-## Что сказал Opus (краткий пересказ)
+## Полный анализ Опуса 4.8
 
-**Подтвердил:** направление правильное — чинить корень (PMTU blackhole), а не симптом (Local + 4 реплики).
+### Главное уточнение
 
-**Уточнил:**
+`mtu` в cilium-config — это MTU **underlay-сети** (физической сети между нодами), а НЕ туннеля. Cilium сам вычитает 50 байт на Geneve:
 
-1. `mtu` в cilium-config — это underlay-MTU. Cilium сам вычитает 50 байт. `mtu: 1450` → туннель 1400.
-2. ConfigMap сам не применяется — нужен `rollout restart ds/cilium`.
-3. iptables как fallback ненадёжен с Cilium (eBPF обходит netfilter FORWARD).
-4. Понижение MTU безопасно, но число надо измерять, а не гадать.
-5. Итоговое состояние `Cluster` + корректный MTU + `replicaCount: 2` — чистое и согласованное.
+```
+mtu: 1450  →  tunnel/pod MTU = 1450 − 50 = 1400
+```
 
----
+По умолчанию Cilium автодетектит underlay 1500 → туннель 1450. Если stall всё равно происходит — значит реальный underlay < 1500. Поэтому нужно измерять, не гадать.
 
-## Моё мнение
+### Подводные камни
 
-Замер сделан, число подтверждено. План готов к передаче девопсу. Это одно изменение — не костыль, а исправление конфигурации кластера под реальный underlay MTU. Делать.
+- **ConfigMap сам не применяется.** Нужен `kubectl rollout restart ds/cilium -n kube-system` — без этого агенты продолжат работать со старым MTU.
+- **Существующие TCP-соединения не поменяют MSS** — эффект только на новые соединения после рестарта.
+- **Нужен рестарт подов приложения** (ingress, drhider) — veth-интерфейс пода получает MTU при создании. Для транзитного (ingress) трафика обновления маршрутов ноды обычно достаточно на новых соединениях, но для чистоты — пересоздать.
+- Пересоздавать туннели вручную не нужно — рестарт агента переинициализирует `cilium_geneve` device.
+- **Установленный вручную `externalTrafficPolicy: Local`** надо вернуть на `Cluster` через `kubectl patch` (ставился не через Helm, сам не откатится).
+
+### Риски для других сервисов
+
+`mtu` — параметр всего кластера, влияет на ВСЕ поды и ВСЕ ноды. **Понижение MTU безопасно** (меньше = консервативнее). Максимум — небольшой рост числа пакетов / микроскопическая потеря throughput. Функционально ничего не ломает.
+
+Риск в момент раскатки: `rollout restart ds/cilium` перезапускает агенты по нодам. eBPF-датаплейн переживает рестарт (трафик идёт), но возможны короткие блипы. Лучше делать в окно.
+
+Настоящий риск — только если поставить **слишком высокий** MTU (проблема останется) или **слишком низкий без нужды** (лишний оверхед). Поэтому критически важен замер.
+
+### iptables как альтернатива
+
+**Не равноценен и с Cilium может не сработать.** Cilium с eBPF-датаплейном / kube-proxy replacement обходит netfilter `FORWARD` для трафика подов. Правило в `mangle/FORWARD` может просто не видеть нужные пакеты.
+
+`--clamp-mss-to-pmtu` берёт MSS из PMTU исходящего маршрута. Если MTU маршрута неверен — клампинг будет неправильным. Надёжнее явный `--set-mss 1400`.
+
+На какую ноду: kube-vip раздаёт VIP на **все 4 ноды** → правило нужно на всех (DaemonSet/node-level).
+
+Вывод: iptables — костыль-fallback, который с Cilium может оказаться нерабочим. **Правильный путь — `cilium-config`**, потому что Cilium ставит `advmss` на маршрутах (тот же MSS clamping, но нативно в eBPF-датаплейне).
+
+### Верификация после изменения
+
+```bash
+# Проверить что Cilium применил MTU
+kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep -i mtu
+ip link show | grep -E 'cilium|geneve'      # MTU tunnel-девайса
+ip route show | grep -E 'advmss|mtu'         # advmss на cilium-маршрутах
+
+# Проверить MSS в SYN-пакетах
+tcpdump -ni any 'tcp[tcpflags] & tcp-syn != 0' -vv | grep mss
+```
+
+Функционально: файл >5 MB через drhider — без паузы 51с. F5 без ERR_TIMED_OUT.
+
+### Более грамотная альтернатива на будущее
+
+Cilium **DSR + `kubeProxyReplacement`** убирает cross-node SNAT на обратном пути целиком — двойной инкапсуляции return-трафика (главная причина stall) просто не возникает. Но это меняет всю сетевую конфигурацию, для быстрого фикса — избыточно.
+
+### Итоговый вердикт
+
+Путь правильный (фикс корня, а не симптома). Конечное состояние `Cluster + корректный MTU + replicaCount: 2` — чистое и согласованное: убирает разом и ручной scale, и Local-костыль.