Мітка на 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 або коли платформі потрібне перезавантаження, щоб змінити розмір таблиці? Бюджет, який витримує ці питання, вартий більше, ніж кількість міток, що працює лише на папері.

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