Отображение метки для маршрутизации, масштабируемость генерации меток

В маршрутизаторах с поддержкой MPLS есть уникальный ярлык, сгенерированный для префикса Destination в таблице маршрутизации, или это для следующего шага в таблице маршрутизации, если не оба, как сопоставление между уникальными метками и записью таблицы маршрутизации? Кроме того, если это для префикса Destination, каково оно? В соответствии с моим пониманием максимальное значение метки равно 2 ^ 20 = 1048576. Что, если количество записей таблицы маршрутизации больше 1048576?

9 голосов | спросил Hemanth 18 12013vEurope/Moscow11bEurope/MoscowMon, 18 Nov 2013 07:16:41 +0400 2013, 07:16:41

2 ответа


6
  

- это уникальная метка, созданная для префикса Префикса в таблице маршрутизации, или это для следующего шага в таблице маршрутизации? ... я видел сценарии клиентов, приближающиеся к 1 миллиону маршрутов ... Но у MPLS нет общих правил для генерации меток? Не существует ли общего правила, согласно которому уникальная метка должна быть сгенерирована для каждого префикса назначения или для одного из них? или это просто конкретная реализация?

Кажется, есть немного путаницы. Маловероятно, что кто-то захочет выделить уникальный ярлык для каждого интернет-маршрута. Хорошо спроектированная сеть MPLS должна выделять метки на основе префиксов IGP, привязанных к вашему BGP next-hops (ref RFC 3031, раздел 4.6 ).

Таким образом, я не уверен, что 1 миллион ярлыков в LFIB сегодня является серьезным ограничением дизайна MPLS.

ответил Mike Pennington 18 12013vEurope/Moscow11bEurope/MoscowMon, 18 Nov 2013 07:47:53 +0400 2013, 07:47:53
3

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

Менеджеры лейблов сегодня у крупных поставщиков (CSCO, JNPR, по крайней мере) запрограммированы так, чтобы им требовалось непрерывное приложение для каждого ярлыка. Конечно, это может быть исправлено с некоторой стоимостью в производительности и сложности, но, безусловно, это еще одна проблема, которую следует учитывать.

Некоторые сервисы MPLS довольно голодны для пространства ярлыков в ядре, в основном это не имеет значения, поскольку мы можем маскировать их под нашей меткой IGP.
Нам нужно помнить, что MPLS - это не только IP, но и FEC, если нам нужно дать какую-то услугу по другому лечению /пути в ядре, нам нужен новый FEC.

Есть несколько дискуссий о поддержке мега-ярлыков и большие ярлыки , их варианты использования , хотя более вероятная реализация будет выполняться через специальные ярлыки . Лично я надеюсь /ожидаю, что формат проводки MPLS будет изменен до появления проблемы 2 ^ 20. Поскольку MPLS в основном используется только внутри одной сети оператора, изменение формата проводов очень просто по сравнению с IPv4-gt; миграцией IPV6, поэтому любые проблемы, с которыми мы столкнемся, обращаясь к ним, будут довольно простыми. Некоторые вопросы, которые я хотел бы решить:

  1. Возможность сохранения истории ярлыков в пути
  2. Накладные расходы с низким байтом (TTL, TC являются избыточными в многоуровневых ярлыках)
  3. Удалите необходимость в передаче P 'duck-typing' Полезная нагрузка MPLS (сегодня прерывает ECMP)
  4. Расширяемый по дизайну (специальные метки обозначают огромную байтовую стоимость)
  5. Увеличение пространства надписей
  6. Совместное существование с MPLSv1
ответил ytti 18 12013vEurope/Moscow11bEurope/MoscowMon, 18 Nov 2013 12:03:46 +0400 2013, 12:03:46

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132