Потоки данных: балансировка приватного трафика

Дата: 2026-08-17 Область: путь пакета от клиента внутри приватного сегмента на приватный листенер (10.20.0.100:80 или 10.30.0.100:80) и обратно. Смежный документ: PUBLIC_LB_DATAFLOW.md — балансировка публичного трафика. Источник: lb/pipeline.sh, lb/topology.env, STEP3_SUMMARY.md.

Отличие от публичного случая: клиент может стоять в одном сегменте с бэкендами. Тогда ответ бэкенда уходит клиенту по L2 напрямую, минуя маршрутизацию, и снять с него трансляцию можно только там, где этот кадр виден. Поэтому в приватном сегменте узел работает коммутатором: каждая ВМ подключена отдельным портом моста.

Предпосылка всей схемы: порт ВМ — порт OVS. В целевой среде это выполняется по построению (ВМ подключены к vSwitch), в стенде порты создаёт scripts/attach-segment.sh (make attach). При этом в ОС виртуальных машин не настраивается ничего, адресация заказчика не меняется, а трафик внутри сегмента не блокируется.

1. Участники сегмента

flowchart LR
    subgraph BR["br-lb — OpenFlow datapath"]
        direction TB
        subgraph S2["сегмент 2 — 10.20.0.0/24 · reg0 = 2"]
            P2["p2 · 2<br/>аплинк к шлюзу Docker"]
            HC2["hcif-p2 · 4<br/>10.20.0.253 <b>в ядре</b>"]
            B1["be1 · 10"]
            B3["be3 · 11"]
            C2["cli2 · 12"]
        end
    end

    CLI2["cli2 10.20.0.10<br/><i>клиент: настроен только адрес</i>"]
    BE1["be1 10.20.0.2:8080"]
    BE3["be3 10.20.0.3:8080"]
    GW["шлюз Docker 10.20.0.254<br/><i>egress бэкендов</i>"]
    OTHER["сегмент 3 — 10.30.0.0/24<br/>be2, be4, cli3"]

    C2 <--> CLI2
    B1 <--> BE1
    B3 <--> BE3
    P2 <--> GW
    S2 -.->|"маршрутизация<br/>таблицы 20/21"| OTHER

Шлюз сегмента 10.20.0.1 и VIP листенера 10.20.0.100 отвечают одним MAC — 02:42:0a:14:00:01. По нему пайплайн отличает трафик к маршрутизатору от трафика между ВМ. Сегмент 3 устроен симметрично.

Какие сегменты имеют листенер, задаёт PRIV_LISTENERS в topology.env: пусто — ни одного, "p2" — один, "p2 p3" — оба.

2. Конвейер таблиц приватного пути

flowchart TD
    IN(["Кадр с порта ВМ"]) --> T0["<b>0</b> сегмент по in_port → reg0<br/><b>learn</b> FDB (eth_src → порт)<br/><b>learn</b> adjacency (для адресов своей подсети)"]
    T0 --> T1{"<b>1</b> классификация<br/>по MAC назначения"}

    T1 -->|"arp"| T5["<b>5</b> ARP-респондер<br/>за VIP, шлюз, .253"]
    T1 -->|"icmp echo на VIP<br/>или шлюз"| T6["<b>6</b> ICMP-респондер"]
    T1 -->|"dl_dst = MAC шлюза<br/>+ nw_dst = VIP:80"| T10
    T1 -->|"dl_dst = MAC шлюза<br/>прочий IP"| T15["<b>15</b> обратный путь L3<br/>ct(nat) — для сессий<br/>из другого сегмента"]
    T1 -->|"прочее —<br/>трафик между ВМ"| T24

    T5 -->|"не наш адрес"| T25
    T10{"<b>10</b> листенер<br/>tcp VIP:80"} --> T11["<b>11</b> таблица слотов<br/>reg1 → reg2 (общая<br/>с публичным листенером)"]
    T11 -->|"пул пуст"| DROPF(["drop — fail-close"])
    T11 --> T12{"<b>12</b> применение члена"}

    T12 -->|"<b>член в сегменте клиента</b><br/>mod_dl_dst + ct(commit,nat)<br/><b>без dec_ttl</b>"| T25
    T12 -->|"член в другом сегменте<br/>ct(commit,nat)"| T20["<b>20/21</b> маршрутизация<br/>dec_ttl, adjacency"]
    T20 --> OUTR(["output: порт члена<br/>в другом сегменте"])

    T15 --> T16["<b>16</b> пост-ct"] --> T20
    T24{"<b>24</b> обратная трансляция<br/>сегмента"}
    T24 -->|"nw_src = член, tp_src = 8080<br/>ct(nat): src → VIP:80"| T25
    T24 -->|"прочее — без изменений"| T25
    T25{"<b>25</b> коммутация<br/>FDB по eth_dst"} --> OUTL(["output: порт ВМ"])
    T25 -->|"broadcast или<br/>неизвестный MAC"| FLOOD(["рассылка по сегменту,<br/>кроме входного порта"])

    classDef d fill:#7f1d1d,stroke:#ef4444,color:#fff
    class DROPF d

3. Основной поток: клиент и член пула в одном сегменте

Тот самый случай, ради которого сегмент переведён на порты OVS.

sequenceDiagram
    autonumber
    participant C as cli2 10.20.0.10
    participant OF as br-lb
    participant B as be1 10.20.0.2

    C->>OF: ARP who-has 10.20.0.100
    Note over OF: t1 → t5: респондер за VIP
    OF-->>C: is-at 02:42:0a:14:00:01 (MAC шлюза сегмента)
    C->>OF: SYN 10.20.0.10 → 10.20.0.100:80, TTL 64
    Note over OF: t0: reg0=2, обучение FDB и adjacency
    Note over OF: t1: dl_dst = MAC шлюза, nw_dst = VIP → листенер
    Note over OF: t10 → t11: слот → член пула
    Note over OF: t12: mod_dl_dst = MAC be1,<br/>ct(commit, nat(dst=10.20.0.2:8080))<br/><b>dec_ttl не выполняется</b>
    OF->>B: t25: FDB → порт be1
    Note over B: client=10.20.0.10 — исходный адрес клиента<br/>served=10.20.0.2:8080 — трансляция 80 → 8080
    B->>OF: ответ src=10.20.0.2:8080 → 10.20.0.10,<br/>dst MAC = MAC клиента (сосед по L2)
    Note over OF: t1: dl_dst ≠ MAC шлюза → t24
    Note over OF: <b>t24</b>: ct(nat) → src = 10.20.0.100:80
    OF->>C: t25: FDB → порт cli2
    Note over C: ответ от 10.20.0.100:80, TTL 64

Обратный кадр не адресован балансировщику вовсе — бэкенд отправляет его соседу напрямую. Через мост он проходит только потому, что порт ВМ — порт OVS. Именно здесь, в таблице 24, снимается трансляция.

Для ВМ ничего не изменилось: TTL не уменьшен, значит клиент и бэкенд по-прежнему L2-соседи, а балансировщик не стал для них маршрутным хопом.

4. Второй поток: член пула в другом сегменте

Тот же листенер, но слот выбрал члена из соседнего сегмента — работает обычная маршрутизация.

flowchart LR
    C["cli2<br/>10.20.0.10"] -->|"dst=10.20.0.100:80"| A["t0/t1: reg0=2,<br/>dl_dst = MAC шлюза"]
    A --> B["t10 → t11 → t12<br/>reg2 указывает на be2:<br/>DNAT 10.30.0.2:8080"]
    B --> D["t20: LPM /24 10.30.0.0<br/><b>dec_ttl</b>, src MAC = p3"]
    D --> E["t21: dst MAC = be2,<br/>output порт be2"]
    E --> BE2["be2<br/><i>client=10.20.0.10</i>"]
    BE2 -->|"маршрут 10.20.0.0/24<br/>via 10.30.0.1"| F["t1: dl_dst = MAC шлюза → t15<br/>ct(nat): src → 10.20.0.100:80"]
    F --> G["t20 → t21: adjacency клиента,<br/>выученная в t0"] --> C

Клиенту оба пути неотличимы — ответ приходит от 10.20.0.100:80. Разница видна только по TTL: 64 от соседа по сегменту против 63 через маршрутизацию.

5. Остальной трафик сегмента

Балансировка не мешает обычной работе сегмента: всё, что не адресовано VIP, коммутируется без трансляции.

flowchart TD
    A["cli2 → be1:8080 напрямую,<br/>минуя VIP"] --> B["t1: dl_dst = MAC be1 → t24"]
    B --> C["t24: ct без записи —<br/>изменений нет"] --> D["t25: FDB → порт be1"]

    E["be1 → be3:8080<br/>внутри сегмента"] --> F["t1 → t24 → t25"]
    F --> G["t25: FDB → порт be3"]

    H["be1 → 1.1.1.1<br/>default via 10.20.0.254"] --> I["t1 → t24 → t25"]
    I --> J["t25: FDB → аплинк p2 →<br/>docker-бридж → NAT хоста<br/><i>профиль A: мимо балансировки</i>"]

    K["ARP между ВМ"] --> L["t5: не наш адрес → t25"]
    L --> M["t25: рассылка по портам сегмента"]

    N["health-проба<br/>10.20.0.253 → be1:8080"] --> O["t0: in_port = hcif-p2<br/>t1 → t24 → t25 → порт be1"]

Про пробы: они уходят с уникального адреса узла .253, а не с VIP. Если бы источником был VIP, ответ бэкенда попал бы в обратную трансляцию и до пробера не дошёл. Правило таблицы 24 ответ на пробу видит, но ct записи для него не находит и пропускает без изменений.

6. Таблица решений приватного пути

Таблица	Матч	Действие	Комментарий
0	`in_port` = порт сегмента	`reg0` + `learn` FDB	мост становится обучающимся коммутатором
0	то же, `ip`, `nw_src` из подсети сегмента	+ `learn` adjacency	нужно для возврата ответов из другого сегмента; с аплинка не обучаем, иначе в t21 попал бы внешний мир
1	`dl_dst` = MAC шлюза, `nw_dst` = VIP, `tp_dst` = 80	→ t10	листенер сегмента
1	`dl_dst` = MAC шлюза, `ip`, `nw_dst` = VIP	drop	адрес занят, листенер выключен — видно по счётчику
1	`dl_dst` = MAC шлюза, `ip`	→ t15	транзит и обратный путь L3
1	прочее	→ t24	трафик между ВМ
5	`arp_tpa` = VIP, шлюз или `.253`	ответ `IN_PORT`	MAC-ом порта сегмента
5	прочий ARP	→ t25	ВМ резолвят друг друга сами
10	`tcp`, `nw_dst` = VIP сегмента	`multipath` → t11	тот же `pool_id` и хэш, что у публичного
12	`reg0` = сегмент члена	`mod_dl_dst` + `ct(commit,nat)` → t25	без `dec_ttl`
12	прочее	`ct(commit,nat)` → t20	член из другого сегмента
24	`nw_src` = член, `tp_src` = 8080	`ct(nat)` → t25	снимает DNAT с ответа соседу
24	prio 0	→ t25	обычный трафик проходит нетронутым
25	`eth_dst` из FDB	`output`	записи `learn`, `idle_timeout` 300 с
25	broadcast или неизвестный MAC	рассылка по сегменту	порт входа OVS исключает сам

7. Где поток обрывается

Точка	Причина	Как увидеть
t0 prio 0	кадр с порта, не отнесённого к сегменту — ВМ не подключена	`make ports`, затем `make attach`
t1 prio 125	обращение на VIP при выключенном листенере	`lbctl flows 1`
t11 prio 0	пул без живых членов — fail-close	`make slots`
t20 prio 0	назначение без маршрута	`lbctl flows 20 \| grep priority=0`
t21 prio 0	adjacency клиента неизвестна — запись `learn` истекла	`lbctl flows 21`
t25 prio 0	кадр без сегмента в `reg0`	`make fdb`

8. Осмотр

make trace SRC=10.20.0.10 SPORT=40000 SEG=p2   # путь сессии по таблицам
make fdb                                        # выученные MAC и счётчики рассылки
make ports                                      # подключены ли ВМ сегментов
docker compose exec lb-router lbctl flows 24    # счётчики обратной трансляции
docker compose exec cli2 curl -s http://10.20.0.100/

В Final flow трассировки коммутируемого пути nw_src остаётся клиентским, nw_ttl не уменьшен, а вывод происходит из таблицы 25 в порт члена.

9. Ограничения приватного пути

Порты ВМ должны быть портами OVS. Если между клиентом и бэкендом окажется коммутатор, который SDN не контролирует, ответ бэкенда мост не увидит, и кейс не решается ничем, кроме SNAT — то есть с потерей IP клиента.
Весь внутрисегментный трафик проходит через узел. Пропускная способность узла становится пропускной способностью сегмента.
Обратная трансляция опирается на ct. Stateless-вариант (nw_src=member, tp_src=8080 → VIP:80) потребует аккуратного исключения трафика, который бэкенд сам инициирует с порта 8080.
FDB без старения короче 300 с и без ограничения на число MAC в сегменте.
Неизвестный unicast и unicast-ARP рассылаются флудом — обычное поведение обучающегося коммутатора.
В стенде порты ВМ исчезают при пересоздании контейнера — нужен make attach. В целевой среде порты создаёт гипервизор.
Только TCP и только IPv4; ICMP-ошибки и фрагменты — как и в публичном пути, вне рамок.

15 KiB Raw Blame History Unescape Escape