ECMP к одному VTEP: откуда берётся энтропия VXLAN

Утверждение, что многовершинная маршрутизация равной стоимости бессмысленна для маршрута к хосту, повторяется достаточно часто, чтобы звучать правдой. /32 выбирает адрес назначения, и ничто в этом выборе не ограничивает пакет одним физическим каналом. Когда пункт назначения — удалённая оконечная точка туннеля VXLAN, несколько следующих переходов могут нести разные потоки наложенной сети, и делают ли они это, зависит от того, что разрешено видеть хешу пересылки. Остальное — арифметика во внешнем заголовке, а не свойство префикса.

Маршрут определяет достижимость; хеш определяет распределение.

Миф: /32 означает один путь

OSPF может сообщать о достижимости равной стоимости до loopback VTEP, тогда как таблица пересылки устанавливает группу следующих переходов для того же префикса. Протокол предоставляет кандидатов; платформа решает, какие из них пригодны и как назначается пакет. Ни один протокол маршрутизации не вычисляет новый хеш для каждого инкапсулированного кадра. Именно это разделение объясняет, почему два маршрутизатора с одинаковыми маршрутами всё равно могут распределять трафик по-разному.

Смотрите на установленную запись пересылки, а не только на отображение маршрута, потому что ограничения оборудования или политики могут отбросить кандидатов, которые плоскость управления всё ещё объявляет.

Откуда должна появляться энтропия

Между двумя VTEP внешние адреса источника и назначения остаются неизменными, а порт назначения UDP в обычном развёртывании равен 4789. Хеш, читающий только эти значения, видит постоянный вход и возвращает постоянный путь. Что-то во внешнем заголовке должно меняться, и VTEP — это устройство, которое может это обеспечить.

RFC 7348 предлагает выводить порт источника UDP из полей внутри инкапсулированного кадра. Тогда разные внутренние разговоры порождают разные внешние кортежи, что даёт обычному транспортному хешу материал для работы.

Если оборудование пересылки может заглянуть глубже в пакет, проверьте, какие внутренние поля поддерживает его реализация хеша. Эту глубину не следует считать требованием для каждого устройства underlay, поскольку одно лишь изменение порта источника уже выявляет полезные различия.

Проверьте хеш, который вы действительно получаете

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

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

Один порт источника, встречающийся во множестве разных внутренних разговоров, означает, что VTEP не меняет поле, и никакая настройка underlay не распределит нагрузку. Множество разных портов при одном используемом следующем переходе указывает скорее на группу пересылки.

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

Что не означает равномерное распределение

Хеш по потоку предназначен для удержания одного разговора на одном пути, пока его входы и доступный набор путей не меняются. Поэтому одна большая передача TCP не объединяет все uplink-и, и добавление каналов не ускорит этот поток. Это нормальное поведение, а не неисправность.

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

Тестируйте с репрезентативными парами адресов, транспортами и скоростями по утверждённому плану и держите выбор членов агрегации каналов отдельно от выбора маршрутизируемой многовершинности, потому что два этапа хеширования складываются в собственный шаблон. Заполненная группа следующих переходов плюс видимая внешняя энтропия объясняют результат; длина префикса — нет.