Теоретические основы и архитектура

Flex-Algorithm превращает IGP в средство Traffic Engineering без контроллера. Оператор описывает «плоскость» один раз: тип метрики, ограничения по affinity, priority. Каждый узел, который к ней присоединился, считает отдельный SPF в урезанной топологии и анонсирует собственный Prefix-SID алгоритма 128-255. Так можно получить плоскость с минимальной задержкой, плоскость без дорогих линков или две полностью разделённые плоскости для дублирования, а трафик VPN направить в нужную через color и SR-TE. Во второй части урока разбирается проблема, о которой часто забывают при быстрой защите: микропетли, возникающие, когда узлы сходятся в разное время. Вы увидите, чем защита от микропетель (локальная задержка и SID-список пути) отличается от TI-LFA, как они работают вместе и как это меняется внутри Flex-Algo плоскости.

Flex-Algorithm: идея и числа

Flexible Algorithm (RFC 9350) переносит часть работы SR-TE в IGP. Вы уже знаете, что стандартный Prefix-SID привязан к алгоритму 0 (обычный SPF по метрике IGP) и что Strict SPF (алгоритм 1) запрещает перенаправление. Номера 128-255 отданы оператору: каждый из них - собственная «плоскость» со своим определением пути. Определение называется FAD (Flex-Algorithm Definition) и содержит номер алгоритма, тип метрики, тип расчёта, priority и набор ограничений. Тип метрики: 0 - метрика IGP, 1 - минимальная односторонняя задержка линка (её либо измеряют и анонсируют IGP-расширениями RFC 8570 и RFC 7471, либо задают статически), 2 - TE-метрика. Тип расчёта пока один - SPF. Ограничения - affinity (exclude-any, include-any, include-all по битам admin group; расширенные группы позволяют больше 32 бит) и exclude SRLG. Флаг M меняет способ учёта метрики префикса. Link-атрибуты для Flex-Algo передаются как обычные TE-расширения IS-IS или в ASLA (RFC 8919, RFC 8920) с битом приложения Flex-Algo.

Участие, выбор FAD и расчёт

Узел участвует в плоскости, если он явно анонсировал алгоритм в SR-Algorithm sub-TLV (IS-IS) или в аналоге OSPF и поддерживает расчёт, описанный в FAD. Определение может быть задано на нескольких узлах: если определения конфликтуют, побеждает FAD с наибольшим priority, при равенстве - с наибольшим идентификатором узла. Поэтому FAD обычно анонсируют минимум два узла с одинаковой конфигурацией, а ошибка в копировании ограничения даёт плоскость, различную у разных узлов. Узел, который не поддерживает FAD (метрику, ограничение, тип расчёта), в плоскости не участвует. Расчёт выполняется отдельно для каждого алгоритма: топология урезается (убираются линки по affinity и SRLG, и узлы, не анонсировавшие алгоритм), потом выполняется SPF по метрике из FAD. Если нужный префикс в такой топологии недостижим, трафика алгоритма к нему нет вовсе, и это отличает Flex-Algo от алгоритма 0: возвращаться на другой алгоритм автоматически он не будет.

Prefix-SID на алгоритм и пересылка

Для каждого алгоритма узел анонсирует свой Prefix-SID: в Prefix-SID sub-TLV есть поле Algorithm. Индексы берут из того же SRGB, что и для алгоритма 0, но выделяют отдельный индекс на каждую пару (узел, алгоритм): в этом уроке PE2 имеет 16002 для алгоритма 0 и 16102 для алгоритма 128. На каждом узле плоскости в LFIB появляется запись для метки 16102, ведущая по кратчайшему пути плоскости. Узлы вне плоскости записей не имеют, и пакет с этой меткой будет отброшен, поэтому точку входа нужно использовать только там, где путь известен. Количество меток растёт линейно с числом узлов и алгоритмов: планируйте диапазон индексов и SRGB заранее. Область действия Flex-Algo - домен IGP (область или уровень); для межобластных и межпроцессных путей используют SR-TE с сегментом алгоритма, а поддержка распространения Flex-Algo между областями зависит от платформы.

Steering и сценарии

Трафик попадает в плоскость тремя способами: SR Policy, где первым сегментом стоит Prefix-SID алгоритма (его можно задать явно), ODN-шаблон с указанием алгоритма для динамического пути (color 200 привязывается к алгоритму 128 - этот приём вы увидите в конфигурации) и BGP/service-маршруты, у которых next hop резолвится в префикс алгоритма на платформах, где это реализовано. Типовые применения: низкая задержка (метрика delay), исключение линков (аренда, спутник, дорогой транзит), два изолированных слоя A и B (include-any A или B) для дублирования, региональные или «слайс»-плоскости. Достоинство - нет контроллера и политик на каждый PE: плоскость определена один раз. Ограничение - всего 128 алгоритмов и совпадающие FAD на всех узлах.

Микропетли

Микропетля - короткая петля пересылки после изменения топологии (RFC 5715). Узлы завершают SPF и обновляют FIB в разное время: узел A уже переключился на новый путь, который ведёт через B, а B ещё использует старый, и пакеты между ними ходят, пока B не сошёлся (обычно от десятков до сотен миллисекунд). Триггеры: падение линка, возвращение линка, изменение метрики, overload bit. Последствия: потери, дублирование, рост TTL-expired и перегрузка линков. Защита бывает двух видов. Локальная задержка (RFC 8333): узел после изменения откладывает обновление RIB на заданное время (в конфигурации rib-update-delay, часто по умолчанию несколько секунд, у разных платформ различается), давая соседям сойтись. Защита на SR: пока действует задержка, узел направляет трафик не обычным путём, а списком SID нового (post-convergence) пути, который заведомо свободен от петель, потому что каждый его сегмент жёстко задаёт следующий узел. Для SR-варианта опирайтесь на актуальные версии черновика draft-bashandy-rtgwg-segment-routing-uloop и на документацию платформы; номер RFC проверяйте отдельно.