Картографське позначення маршруту, масштабування поколінь міток

У маршрутизаторах, що підтримуються MPLS, унікальна мітка, що генерується за префіксом призначення в таблиці маршрутизації, чи це за наступним стрибком у таблиці маршрутизації, якщо не обидва, як відбувається відображення між унікальними мітками та записом таблиці маршрутизації? Крім того, якщо він вказаний за префіксом призначення, наскільки він можливий? Як на мене зрозуміло, максимальне значення мітки становить 2 ^ 20 = 1048576. Що робити, якщо кількість записів таблиці маршрутизації перевищує 1048576?

— Гемант
джерело

Ви серйозно пропонуєте, що ви дивитесь на сценарій, коли хтось наближається до 1 мільйона записів LFIB, або це теоретичне питання?

— Майк Пеннінгтон

Зараз я працюю з L3, я бачив сценарії клієнтів, що на маршрутизаторах Edge наближаються до 1 мільйона маршрутів (повних маршрутів в Інтернеті). Це число не перейшло. Але я бачив загальну кількість публікацій, близьких до півмільйона.

— Хемант

скільки маршрутів IGP + ярлики RSVP-TE? Це погана конструкція прив’язувати етикетку до кожного маршруту в Інтернеті. Вам слід прив'язувати мітки лише до всіх наступних переходів BGP у вашій таблиці IGP.

— Майк Пеннінгтон

Прив’язування мітки до BGP nexthop має сенс. Але MPLS не має загальних рекомендацій щодо створення етикетки? Чи не існує загального правила, яке говорить про те, що унікальна мітка повинна бути створена за призначенням-префіксом або за наступним маркером? чи це просто конкретна реалізація?

— Хемант

Чи допомогла вам якась відповідь? якщо так, то слід прийняти відповідь, щоб питання не з’являлося вічно, шукаючи відповідь. Крім того, ви можете надати та прийняти власну відповідь.

— Рон Моупін

Відповіді:

це унікальна мітка, сформована за префіксом призначення в таблиці маршрутизації, або це наступний перехід у таблиці маршрутизації? ... я бачив сценарії клієнтів, що наближаються до 1 мільйона маршрутів ... Але MPLS не має загальних рекомендацій щодо створення ярликів? Чи не існує загального правила, яке говорить про те, що унікальна мітка повинна бути створена за призначенням-префіксом або за наступним маркером? чи це просто конкретна реалізація?

Здається, невелика плутанина. Навряд чи хтось захоче виділити унікальну етикетку на Інтернет-маршрут. Добре розроблена мережа MPLS повинна виділяти мітки на основі префіксів IGP, які пов'язані з вашими BGP наступними переходами (див. RFC 3031, розділ 4.6 ).

Тому я не впевнений, що 1 мільйон етикеток в LFIB є серйозним обмеженням дизайну MPLS сьогодні.

— Майк Пеннінгтон
джерело

Згідно з розділом 4.6 rfc3031, всі основні маршрутизатори будуть виділяти мітки для префіксів igp. Але BGP виділить унікальну мітку для кожного маршруту (маршруту BGp), який він надсилає одноліткові BGP. Але тут знову BGP може рекламувати тисячі маршрутів, так? Що буде, якщо кількість маршрутів BGP перевищить 2 ^ 20?

— Хемант

@Saran Ви маєте рацію, можливо, у такому сценарії не вистачає міток (наприклад, RFC4364, варіант b). Що станеться, ви не можете рекламувати жодну NLRI, для якої потрібна нова лейбла. Я думаю, що це досить малоймовірно і технічно, якщо PE має такий же наступний перехід, що стосується префікса, ви можете поділитися лейблом. Оскільки opt-B потребує згортання всіх ярликів IGP, VPN в одну мітку, трохи простіше уявити сценарій, де це може статися, але мені це не дуже імовірно.

— ytti

@Saran, в сценарії, про який ви згадали, це міжповерховий VPL -MPLS VPN . Проста маршрутизація BGP, яку, здається, ви задаєте в оригінальному запитанні, не позначає мітки для маршрутів BGP за замовчуванням. Будь-який сценарій MPLS VPN міг би вичерпати мітки, що поширюються VPNv4; в цей момент вам потрібно сегментувати клієнтську базу на окремих маршрутизаторах, якщо ви не працюєте між AS.

— Майк Пеннінгтон

Варіант C масштабує як звичайний MPLS, так як це звичайний стек [IGP, VPN]. Однак Варіант B - це лише [мітка], для чого в кінцевому підсумку потрібно відобразити в ASBR [IGP, VPN]. Отже, хоча в OptionC частина VPN не повинна бути унікальною для двох PE, в OptionB кожна комбінація [IGP, VPN] повинна бути унікальною по каналу ASBR <-> ASBR.

— ytti

@ytti - "Я думаю, що це досить малоймовірно і технічно, якщо PE в далекому кінці є однаковим наступним стрибком, для префікса ви можете поділити етикетку". Чи не існує жорсткого правила, для якого потрібно створити мітку кожен PRefix (префікс BGp)? Я прекрасно розумію, що краще поділити одну мітку для кількох префіксів, якщо вони слідують однаковому шляху для перемикання. Але питання в тому, як це вирішено? Як маршрутизатор вниз за течією дізнається або вирішить, якими маршрутами поділити одну мітку. Це просто черговий магазин? якщо багато маршрутів мають один і той же наступний магазин, вони отримають лише одну мітку?

— Хемант

Точний практичний сценарій, коли мітки можуть закінчитися, є дискусійним. Є також деякі питання з домоволодіння, які безпосередньо не пов’язані із закінченням міток, але сприяють цьому.

Сьогодні менеджери етикеток у великих постачальників (як мінімум, CSCO, JNPR) запрограмовані таким чином, що їм потрібен постійний блок на додаток етикетки. Звичайно, це може бути виправлено з певними витратами на продуктивність та складність, але це, безумовно, ще одне питання.

Деякі сервіси MPLS досить голодні щодо місця міток у ядрі, вкрай, в основному, це не має значення, оскільки ми можемо замаскувати їх під нашою "міткою IGP".
Нам потрібно пам’ятати, що MPLS - це не лише ІР, це FEC, якщо нам потрібно надати якісь різні послуги / шлях в ядрі, нам потрібен новий FEC.

Існують певні дискусії щодо підтримки мега-етикетки та великих етикеток , випадків їх використання , хоча більш ймовірна реалізація відбуватиметься через мітки спеціального призначення . Особисто я сподіваюся / очікую, що формат MPLS буде змінено до того, як 2 ^ 20 стане проблемою. Оскільки MPLS використовується в основному лише в одній операторській мережі, змінити провідний формат дуже просто порівняно з міграцією IPv4-> IPV6, тому те, що коли-небудь виникнуть проблеми, вирішити їх буде досить просто. Деякі питання, які я хотів би вирішити:

Можливість збереження історії етикетки під час транзиту
Низький байт накладних витрат (TTL, TC є надлишком у складених мітках)
Видаліть потребу в транзитному навантаженні MPLS, що набирає качку (перериває ECMP сьогодні)
Розширюється за дизайном (мітки спеціального призначення вводять величезні витрати на байт)
Збільшений простір міток
Співіснування з MPLSv1

— ytti
джерело