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 может продолжать отбрасывать часть трафика.

Добавляется собственная служебная нагрузка:

Поэтому сначала проверяют underlay: адреса, маршруты, потери, задержку, MTU, ECMP и firewall. Затем — overlay.

Overlay и ECMP

Внешняя сеть принимает решение по внешним заголовкам. Если все внутренние потоки между двумя узлами получают одинаковую внешнюю пару адресов и портов, underlay может считать их одним большим потоком и отправлять по одному ECMP-пути.

Некоторые реализации меняют UDP source port на основе хеша внутреннего потока. Тогда разные пользовательские соединения лучше распределяются между равнозначными путями. Это важная деталь для производительности фабрики ЦОД, хотя конечные виртуальные машины о ней не знают.

Где ставить границу

Overlay можно завершить на:

Чем ближе конечная точка к приложению, тем меньше незашифрованный участок и точнее политики. Но тем больше агентов, ключей, туннелей и состояний приходится обслуживать.

Практический порядок диагностики

  1. Проверить достижимость внешних адресов конечных точек.
  2. Проверить разрешённый внешний протокол и порт.
  3. Измерить максимальный пакет без фрагментации.
  4. Посмотреть route lookup до внешнего адреса туннеля.
  5. Проверить состояние интерфейса туннеля.
  6. Снять дамп одновременно до и после инкапсуляции.
  7. Только после этого разбирать маршруты и политики внутри overlay.

Где это ломается

В следующей части поднимемся на L2 и попробуем растянуть Ethernet. Посмотрим, зачем VXLAN понадобился VNI, какую работу выполняет EVPN и почему broadcast-домен через несколько площадок нужно создавать только при наличии уважительной причины.

Предыдущая часть: «SDN без магии: карта видов связности»

Оглавление цикла: «SDN без магии: карта видов связности»

Следующая часть: «L2-overlay: VLAN, VXLAN, Geneve и EVPN»

Схема

#network #selfhosting