Метка на VRF или на префикс? Настоящий счёт ёмкости

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

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

Что на самом деле экономит каждое выделение

Выделение на префикс несёт информацию о пересылке в метке. Выходной маршрутизатор может отправить пакет прямо к нужному соседству без поиска назначения, поэтому оно хорошо масштабируется для больших наборов маршрутов VRF и поэтому расходует одну метку на каждый анонсированный префикс в каждом VRF. Выделение на VRF, например Junos vrf-table-label, анонсирует одну метку на каждый экземпляр маршрутизации и использует эту метку для выбора таблицы VRF; затем маршрутизатор выполняет поиск IP внутри таблицы.

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

Книга меток — маленькая

Метки MPLS конечны, но пространства меток достаточно, чтобы обычные операторы не исчерпали его несколькими тысячами префиксов. Маркировка на VRF действительно помогает на платформах с небольшими аппаратными таблицами меток или в схемах, где один VRF несёт полный поток интернета, а метки на префикс умножали бы спрос на метки на число маршрутов. Это реальные ограничения, и именно они являются причиной существования функции. Ни одно из них не о числе префиксов в таблице.

Посчитайте метки и для сервиса, и для транспорта, прежде чем выбирать. Схема на VRF по-прежнему требует транспортных меток для loopback и для каждого перехода на пути, и по-прежнему требует состояния соседства. Если проектная записка считает только сервисные метки, экономия измеряется не в той книге.

Потоки маршрутов стоят памяти раньше меток

Каждый полученный путь расходует память плоскости управления, обработку обновлений и время сходимости, независимо от того, использует VRF одну метку или десять тысяч. Полный поток интернета внутри VRF дорог из-за путей BGP, RIB, записей FIB и суеты за ними, а не из-за метки перед таблицей. Тот же поток увеличивает и радиус влияния утечки маршрутов или ошибки политики внутри этого арендатора.

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

Когда маркировка на VRF — правильное значение по умолчанию

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

Это неправильное значение по умолчанию, когда документация платформы связывает функцию с конкретными ограничениями оборудования или выпуска, или когда схема зависит от решений о пересылке на префикс на выходе. Прочитайте собственную справку statement платформы, прежде чем предполагать поведение; команда Junos документирована, но именно ограничения оборудования и выпуска вокруг неё определяют развёртывание.

Бюджет, который можно защитить

Постройте обоснование ёмкости как пять отдельных чисел: полученные пути, выбранные маршруты, установленные записи пересылки, сервисные метки и транспортные метки. Добавьте состояние next-hop и соседства, число арендаторов и модель резервирования. Снимок беспроблемного пути одного VRF не является числом масштаба, а номинальный размер пространства меток не является доступной аппаратной таблицей.

Затем договоритесь и о режиме отказа, а не только об установившемся состоянии. Что происходит, когда поток вырастает наполовину, когда арендатор добавляет второй VRF или когда платформе нужна перезагрузка, чтобы изменить размер таблицы? Бюджет, который выдерживает эти вопросы, стоит больше, чем число меток, работающее только на бумаге.

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