Underlay и overlay: сеть под сетью

Цикл «Виды связности и SDN», часть 2. Предыдущая часть: «SDN без магии: карта видов связности».
Ось: underlay и overlay (транспорт).
Представим, что сервер в офисе должен общаться с виртуальной машиной в облаке так, будто они находятся в одной внутренней сети. Между ними уже есть Интернет. Мы не меняем Интернет, а создаём поверх него собственную логическую связность.
Интернет в этой схеме — underlay. Туннель — overlay.
Что происходит с пакетом
Приложение формирует обычный IP-пакет. Overlay-компонент добавляет к нему свой заголовок, затем внешний IP-заголовок. Underlay видит только наружные адреса узлов туннеля и доставляет контейнер целиком.
На принимающей стороне внешние заголовки снимаются, и исходный пакет продолжает путь так, будто никакого Интернета между участниками не было.
VXLAN обычно вкладывает Ethernet-кадр в UDP. Geneve делает похожее, но имеет расширяемые поля параметров. IPIP помещает IPv4-пакет внутрь другого IPv4-пакета. GRE добавляет собственный заголовок между внешним IP и полезной нагрузкой. WireGuard не только инкапсулирует, но и шифрует содержимое.
Внешний заголовок не всегда UDP. IPIP использует IP protocol 4, GRE — protocol 47. У них нет номера TCP- или UDP-порта.
Требования к underlay
Минимальное требование почти всегда одно: адреса конечных точек туннеля должны быть достижимы друг для друга. Но дальше начинаются детали.
Для VXLAN и Geneve межсетевые экраны должны пропускать соответствующий UDP. Порт зависит от реализации, а не только от названия протокола:
| Механизм | Внешний транспорт | Типичный порт |
|---|---|---|
| VXLAN по IANA | UDP | 4789 |
| VXLAN в Linux, Cilium, Flannel | UDP | 8472 |
| VXLAN в Calico | UDP | 4789 |
| Flannel VXLAN на Windows | UDP | 4789 |
| Geneve | UDP | 6081 |
| WireGuard | UDP | 51820; Cilium — 51871 |
| IPIP | IP protocol 4 | порта нет |
| GRE | IP protocol 47 | порта нет |
Если firewall разрешает только TCP и UDP, правило «порт для IPIP» не поможет: такого порта не существует.
Цена заголовков
Обычный Ethernet часто имеет MTU 1500. После добавления внешних заголовков внутри туннеля остаётся меньше места.
Примерные накладные расходы:
| Механизм | IPv4 | IPv6 |
|---|---|---|
| IPIP | 20 | — (это IPv4-in-IPv4) |
| VXLAN | 50 | 70 |
| Geneve без options | ~50 | ~70 |
| WireGuard | 60 | 80 |
VXLAN 50 байт на IPv4 складываются так: внешний IPv4 (20) + UDP (8) + VXLAN (8) + внутренний Ethernet (14). IPIP Ethernet внутрь не кладёт, поэтому налог меньше. Options у Geneve увеличивают размер сверху базовых 50. VXLAN поверх WireGuard складывает расходы обоих слоёв.
Если inner MTU не уменьшить, большой пакет придётся фрагментировать или отправитель должен узнать допустимый размер через Path MTU Discovery. Когда ICMP-сообщения о необходимости уменьшить пакет фильтруются, возникает PMTUD black hole.
Для IPv4 это ICMP Type 3 Code 4 (Fragmentation Needed). Для IPv6 — ICMPv6 Packet Too Big: промежуточные маршрутизаторы IPv6 не фрагментируют, поэтому без PTB большой пакет просто не проходит.
Маленький ping проходит, SSH открывается, а загрузка страницы или передача большого файла зависает. Администратор смотрит на зелёный мониторинг и начинает подозревать приложение. Приложение обычно ни при чём.
Overlay не повышает качество underlay
Если underlay теряет 3% пакетов, WireGuard их не вернёт. Если между площадками 90 мс задержки, VXLAN не сделает 2 мс. Если маршрутизация асимметрична, stateful firewall может продолжать отбрасывать часть трафика.
Добавляется собственная служебная нагрузка:
- keepalive для сохранения NAT mapping;
- сообщения control plane;
- STUN и negotiation для mesh-сетей;
- BFD или другие проверки доступности;
- дополнительная обработка и шифрование.
Поэтому сначала проверяют underlay: адреса, маршруты, потери, задержку, MTU, ECMP и firewall. Затем — overlay.
Overlay и ECMP
Внешняя сеть принимает решение по внешним заголовкам. Если все внутренние потоки между двумя узлами получают одинаковую внешнюю пару адресов и портов, underlay может считать их одним большим потоком и отправлять по одному ECMP-пути.
Некоторые реализации меняют UDP source port на основе хеша внутреннего потока. Тогда разные пользовательские соединения лучше распределяются между равнозначными путями. Это важная деталь для производительности фабрики ЦОД, хотя конечные виртуальные машины о ней не знают.
Где ставить границу
Overlay можно завершить на:
- физическом маршрутизаторе;
- коммутаторе с VTEP;
- гипервизоре;
- Kubernetes-узле;
- отдельном шлюзе площадки;
- клиентском ноутбуке.
Чем ближе конечная точка к приложению, тем меньше незашифрованный участок и точнее политики. Но тем больше агентов, ключей, туннелей и состояний приходится обслуживать.
Практический порядок диагностики
- Проверить достижимость внешних адресов конечных точек.
- Проверить разрешённый внешний протокол и порт.
- Измерить максимальный пакет без фрагментации.
- Посмотреть route lookup до внешнего адреса туннеля.
- Проверить состояние интерфейса туннеля.
- Снять дамп одновременно до и после инкапсуляции.
- Только после этого разбирать маршруты и политики внутри overlay.
Где это ломается
- Inner MTU оставили 1500, а ICMP Fragmentation Needed или IPv6 Packet Too Big отфильтровали.
- Ищут «порт VXLAN», а реализация слушает 8472 вместо 4789 — или наоборот.
- Пытаются открыть «порт IPIP» на firewall, который пропускает только TCP/UDP.
- Overlay считают лечением потерь и асимметрии underlay.
- Все внутренние потоки схлопываются в один ECMP-путь из-за одинаковой внешней 5-tuple.
В следующей части поднимемся на L2 и попробуем растянуть Ethernet. Посмотрим, зачем VXLAN понадобился VNI, какую работу выполняет EVPN и почему broadcast-домен через несколько площадок нужно создавать только при наличии уважительной причины.
Предыдущая часть: «SDN без магии: карта видов связности»
Оглавление цикла: «SDN без магии: карта видов связности»
Следующая часть: «L2-overlay: VLAN, VXLAN, Geneve и EVPN»
