Кратко

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

Победитель изменился, расстояние осталось

Рассмотрим условную сеть с двумя пограничными маршрутизаторами A и B. Это мысленный пример, а не описание аварии. Через каждый получен пригодный маршрут к одному и тому же префиксу; следующие узлы достижимы, правила допуска соблюдены. Через A список AS_PATH короче. Если использовать описанный Cisco порядок выбора, дополнительно зафиксируем равный WEIGHT: этот параметр проверяется раньше LOCAL_PREF. Сначала оба пути имеют LOCAL_PREF 100, затем правило на входе присваивает пути через B значение 200.

При сравнении этих кандидатов в заданных условиях выигрывает B. Короткий AS_PATH больше не решает исход, потому что до него дело не доходит. Меняется не физическое устройство Интернета, а предпочтение принимающей сети. Такой механизм может изменить выбор выхода у внутренних узлов, видящих соответствующие маршруты. Он не означает, что все маршрутизаторы при любых обстоятельствах обязаны переключиться одновременно и одинаково. Документация Cisco по выбору лучшего пути.

Оговорка об одном префиксе принципиальна. Высокий LOCAL_PREF для агрегата не отменяет более специфичный установленный маршрут при поиске по адресу назначения. Выбор BGP между маршрутами к одинаковому префиксу и поиск самого длинного совпадения для пакета — разные операции. Если проверочный трафик попадает под более специфичную запись, он может вообще не испытывать действие измененной политики агрегата.

Сам атрибут — четырехоктетное беззнаковое целое, где большее значение предпочтительнее. Для внешнего маршрута степень предпочтения вычисляется локальной политикой; внутри AS она передается через IBGP. В обычном EBGP атрибут не отправляют, а полученный извне игнорируют. В стандарте отдельно предусмотрено исключение для конфедераций BGP. Общая семантика числа согласована, но его коммерческое значение не установлено для всего Интернета. RFC 4271.

Внутренний ранг не является сертификатом

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

Проверка происхождения маршрута отвечает на другой вопрос. Ее результат можно использовать при формировании локальной политики, но нельзя восстановить факт проверки из величины LOCAL_PREF. RFC 6483 разделяет состояние проверки и его применение при выборе. Для разбора решения нужны оба следа: почему маршрут был допущен и почему он обошел другие допустимые маршруты. Иначе коммерческая метка может выглядеть как техническое подтверждение надежности.

Даже привычная 100 имеет ограниченный смысл. RFC 4277 называет ее распространенным значением по умолчанию, одновременно отмечая отсутствие универсального значения в спецификации. Поэтому при замене оборудования или переносе политики необходимо проверять не только явные установки, но и поведение маршрутов, которые не попали ни под одно специальное правило. Именно там неявное решение может пережить смену команды незамеченным.

В Junos важно также не путать LOCAL_PREF с общей предпочтительностью маршрута, называемой административной дистанцией. Это разные сравнения с разным смыслом чисел. Документация Juniper отдельно объясняет обработку LOCAL_PREF 100 и случая отсутствующего атрибута при передаче маршрутов в BGP. Вывод о поведении конкретной платформы должен опираться на ее правила, а не на сходство названий полей. Juniper: Local Preference for BGP Routes.

Граница проходит через правило сопоставления

Внешний абонент все же может влиять на внутренний выбор провайдера. Для этого провайдер публикует значения Communities, которые сопоставляет своим классам предпочтения. Абонент помечает объявление, а принимающая сторона исполняет согласованное правило. Такая схема описана в RFC 1998. Это не передача обязательного для исполнения LOCAL_PREF через обычный EBGP, а обращение к функции, которую открыл владелец сети.

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

Large Communities позволяют лучше описать функции и область их применения. Однако их структурированность не делает запрос разрешением. RFC 8195 рассматривает классы LOCAL_PREF и ограниченные по области действия функции. В принимающей сети все равно остается собственная таблица соответствия. Ее версия, границы и порядок применения имеют не меньшее значение, чем значение Community, которое прислал клиент.

Полезно отделять этот механизм от соседних инструментов. MED выражает пожелание о входе в соседнюю AS в пределах своих правил сравнения. AIGP переносит накопленную метрику в ограниченной административной среде. LOCAL_PREF — назначенный местной политикой ранг. Если назвать все три «весом маршрута», исчезнет ответ на главный вопрос: кто сообщил исходные данные и кто уполномочен превратить их в решение о выходе.

Согласованность не равна одинаковым цифрам

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

RFC 4271 предупреждает: локальный пересчет предпочтения маршрута, полученного по IBGP, способен привести к устойчивым петлям. Это сильное основание проверять связность политики и пересылки. Но оно не превращается в универсальное требование всегда выставлять всем внутренним узлам одно число. RFC 4272 прямо отмечает отсутствие такого требования. Намеренная региональная политика возможна; ее следует проверять по архитектуре передачи трафика, а не запрещать по одному несовпадению.

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

В документации Juniper по BGP отдельно рассматриваются разрешение следующего узла и превращение выбранного BGP-пути в активный маршрут. Это иллюстрирует, почему значение атрибута, выбранный кандидат и установленная запись не являются одним фактом. Особенности Junos при этом нельзя выдавать за единственно возможный порядок для всех реализаций.

Правильный формат может нести ошибочное решение

Непреднамеренно высокая цифра не является поврежденным атрибутом. RFC 7606, раздел 7.5 различает удаление атрибута, пришедшего от обычного внешнего соседа, и обработку неверной длины внутреннего LOCAL_PREF как отзыва маршрута. Корректно закодированное значение, которому ошибочно дали слишком широкий охват, под эти случаи не попадает. Проверка сообщений защищает от определенного класса ошибок, но не проверяет хозяйственный смысл политики.

Поэтому масштаб изменения нужно считать по совпавшим маршрутам. Одна строка может затронуть тысячи префиксов, если условие охватывает широкую группу. Другая строка изменит лишь узкий набор. Отдельно проверяются семейства адресов, точки подключения правила и исключения. Префикс из заявки на изменение — демонстрация, а не доказательство того, что ничего другого правило не затронуло.

Понижение ранга тоже не равно удалению. RFC 8326 описывает GRACEFUL_SHUTDOWN: низкое предпочтение, с рекомендуемым значением 0, дает альтернативам возможность занять место обслуживаемого пути. Если допустимой альтернативы нет, путь с нулем может остаться выбранным. Закрывать сессию только потому, что на экране появилась нужная цифра, значит пропустить проверку предпосылки — наличия действительного обхода.

Доказать нужно не число, а переход

До применения политики полезно зафиксировать автора решения, целевую группу и условие возврата. Затем проверяются входные альтернативы в Adj-RIB-In, действие правил приема и присвоенные значения. Следующая ступень — распространение по IBGP и выбранный Loc-RIB в нескольких значимых точках. Если число задано верно лишь на границе, а ожидаемого внутреннего выбора нет, следует искать причину в видимости и обработке состояния, а не объявлять изменение завершенным.

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

Возврат проверяется той же цепочкой. Восстановленный файл конфигурации еще не означает повторную оценку всех прежних маршрутов. Route Refresh может запросить актуальные объявления для переоценки, но не задает саму политику. После возврата нужно снова увидеть нужный выбор, установку и передачу. В этом и состоит практическая граница власти LOCAL_PREF: оператор вправе выразить предпочтение, но обязан отдельно показать, что сеть реализовала его в допустимом масштабе.