Кратко

  • Multipath допускает несколько подходящих маршрутов к локальной пересылке, но не гарантирует двойную ёмкость, физическую независимость или равенство байтов.
  • BGP определяет кандидатов, рекурсия и оборудование строят группу, а хеш и состав потоков определяют фактическую нагрузку.
  • Надёжная проверка связывает Adj-RIB-In, RIB, FIB, счётчики участников, очереди и испытания отказа. Снимок таблицы маршрутов показывает лишь один этап.

Половина, которой никто не обещал

Рассмотрим условный механизм, а не реальный инцидент. Два маршрута к одному префиксу проходят multipath-критерии устройства и появляются в ECMP-группе. В плане ёмкости записывают «50/50». Затем крупный долгоживущий поток попадает на участника A, заполняет его очередь, а B остаётся сравнительно свободным.

Сессии BGP могут быть стабильны, оба маршрута — установлены, а ECMP — работать по спецификации. Ошибочной была логика: два участника означают по половине байтов. Хеш распределяет идентификаторы потоков, но не выравнивает их размеры.

RFC 4271 описывает оценку допустимых маршрутов, выбор, установку в Loc-RIB и определение непосредственного next hop. Реализации multipath локально расширяют этот результат дополнительными подходящими путями. Это не создаёт междоменного обещания, что каждый сосед объявит или применит тот же набор. RFC 4271, раздел 9.1.2

Смысл «равных» путей зависит от реализации. Cisco документирует собственные условия и сохраняет назначенный best path для объявления. FRRouting проверяет multipath после предыдущих критериев и позволяет multipath-relax ослабить точное равенство AS_PATH, а Arista описывает иное поведение по умолчанию для этого ослабления в указанном контексте EOS. Это локальные правила допуска, а не доказательство одинаковой ёмкости, независимости или риска. Документация Cisco, документация FRRouting, документация BGP Arista EOS

Три разных решения

Первое — допуск. Какие маршруты доступны, разрешены политикой и достаточно эквивалентны по правилам продукта? maximum-paths задаёт потолок, но не доказывает, сколько участников попало в ASIC.

Второе — построение. Каждый next hop должен рекурсивно разрешиться и быть записан в FIB. Два адреса могут проходить через один туннель, line card или удалённый канал; число маршрутов не доказывает разные домены отказа.

Третье решение принимает хеш для каждого потока. RFC 2991 объясняет, почему сохранение одного пути внутри потока уменьшает переупорядочивание и как смена участников нарушает пересылку. RFC 2992 анализирует hash-threshold ECMP. Равномерный хеш может распределить потоки, но не байты, если размеры потоков различаются. RFC 2991, RFC 2992

Поэтому отдельно доказываются допуск маршрутов, программирование участников и их реальное использование.

Доступная энтропия зависит от видимости

Устройство хеширует только видимые и поддерживаемые поля. В IPv6 flow label способен дать энтропию, когда транспортные заголовки недоступны. RFC 6438 также показывает ограничения туннелей, фрагментов и непрозрачной нагрузки. Множество внутренних соединений с одним внешним tuple может выглядеть как один поток. RFC 6438

Недостаточно написать «хеш по пяти полям». Нужно зафиксировать платформу, семейство, инкапсуляцию, поля, seed и гранулярность. Настройки Arista для seed, polarization и resilient ECMP демонстрируют локальную поверхность реализации, а не универсальный стандарт. Документация Arista

Состав трафика не менее важен. RFC 7424 описывает отображение множества потоков на небольшое число каналов и дисбаланс от крупных потоков. Тысячи коротких сессий могут усредниться; один backup или replication stream — занимать участника часами. Пакеты, байты, очереди, drops и задержка отвечают на разные вопросы. RFC 7424

Обычный ECMP также не обязан учитывать разную пропускную способность участников. Взвешенное или адаптивное распределение — отдельные механизмы с отдельными рисками.

Видеть несколько путей — не значит использовать их

ADD-PATH увеличивает видимость. RFC 7911 разрешает объявлять несколько путей к префиксу без неявной замены, но не обязывает получателя установить их вместе или делить трафик в заданной пропорции. И наоборот, локальный multipath может сочетаться с объявлением одного best path. RFC 7911

PIC готовит быстрое восстановление после отказа; подготовленный резерв не доказывает одновременную нагрузку в штатном режиме. Junos отдельно документирует выбор BGP multipath и load-balancing policy в таблице пересылки. Исторический термин «per-packet» часто означает хеш по потоку и требует чтения в контексте платформы. Документация Junos

От кандидата до пакета

До изменения фиксируются префиксы, семейства, соседи, лимит, владелец и условие rollback. Сохраняются кандидаты Adj-RIB-In и точный результат сравнения; при multipath-relax указывается, что именно ослаблено.

Далее проверяются рекурсивные next hop, домены отказа, идентификатор и состав реально запрограммированной ECMP-группы. Если RIB показывает два пути, а FIB — одного участника, сначала исследуются разрешение, ёмкость и программирование, а не хеш.

За репрезентативный период собираются пакеты, байты, drops и очереди каждого участника, выявляются крупные потоки, запускаются пробы с разными ключами из нужных точек входа. Один ping доказывает только собственный путь. Удаление и возврат участника тоже входят в тест: resilient hashing сокращает перемещения, но не устраняет их полностью.

Rollback завершается не удалением команды, а восстановлением набора кандидатов, RIB, FIB и поведения пакетов.