Сопоставление меток и маршрутов, масштабируемость генерации меток

9

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

Hemanth
источник
Вы всерьез предполагаете, что смотрите на сценарий, когда кто-то приближается к 1 миллиону записей LFIB, или это теоретический вопрос?
Майк Пеннингтон
В настоящее время я работаю с L3, я видел сценарии клиентов, приближающиеся к 1 миллиону маршрутов (полных интернет-маршрутов) в пограничных маршрутизаторах. Он не пересек это число. Но я видел общее количество записей около полумиллиона.
Hemanth
сколько маршрутов IGP + метки RSVP-TE? Плохой дизайн - привязывать ярлык к каждому интернет-маршруту. Вы должны привязывать метки только ко всем следующим переходам BGP в таблице IGP.
Майк Пеннингтон
Привязка метки к BGP имеет смысл. Но MPLS не имеет каких-либо общих руководящих принципов для создания меток? Не существует ли общего правила, согласно которому уникальная метка должна создаваться для каждого префикса назначения или для каждого следующего перехода? или это просто конкретная реализация?
Hemanth
Вам помог какой-нибудь ответ? если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.
Рон Мопин

Ответы:

6

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

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

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

Майк Пеннингтон
источник
В соответствии с разделом 4.6 rfc3031, все основные маршрутизаторы будут выделять метки для префиксов igp. Но BGP выделит уникальную метку для каждого маршрута (маршрут BGp), который он отправляет узлу BGP. Но и здесь BGP может рекламировать тысячи маршрутов, верно? Что произойдет, если количество маршрутов BGP превысит 2 ^ 20?
Hemanth
1
@Saran, вы правы, возможно, в таком сценарии закончились ярлыки (например, RFC4364, вариант b). Что произойдет, вы не можете рекламировать ни один NLRI, который требует нового ярлыка. Я думаю, что это довольно маловероятно и технически, поскольку у PE на дальнем конце есть тот же следующий переход, для префикса, которым вы могли бы поделиться с лейблом. Поскольку opt-B необходимо свернуть все метки IGP, VPN в одну метку, немного проще представить сценарий, где это может произойти, но для меня это маловероятно.
2011 г.
@Saran, в сценарии, который вы упомянули, это MPLS VPN между AS . Простая маршрутизация BGP, о которой вы, кажется, спрашиваете в исходном вопросе, по умолчанию не выделяет метки для маршрутов BGP. Любой сценарий MPLS VPN может закончиться без меток, распространяемых VPNv4; на этом этапе вам нужно сегментировать клиентскую базу на отдельных маршрутизаторах, если вы не используете inter AS.
Майк Пеннингтон,
Вариант C масштабируется как обычный MPLS, так как это обычный стек [IGP, VPN]. Однако вариант B - это просто [метка], который в конечном итоге должен отображаться в ASBR на [IGP, VPN]. Таким образом, хотя в OptionC часть VPN не обязательно должна быть уникальной для двух PE, в OptionB каждая комбинация [IGP, VPN] должна быть уникальной по каналу ASBR <-> ASBR.
Ytti
@ytti - «Я думаю, что это довольно маловероятно и технически, поскольку на дальнем конце PE есть такой же следующий переход, для префикса вы могли бы поделиться меткой.» Нет ли жесткого правила, для которого нужно сгенерировать метку каждый PRefix (префикс BGp)? Я прекрасно понимаю, что лучше использовать одну метку для нескольких префиксов, если они используют один и тот же путь для переключения. Но вопрос в том, как это решается? Как нисходящий маршрутизатор узнает или решит, какие маршруты совместно использовать одну метку. Это просто следующий шоп? если у многих маршрутов один и тот же следующий маршрут, будет ли им назначен только один ярлык?
Hemanth
3

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

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

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

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

  1. Возможность сохранения истории этикетки в пути
  2. Издержки нижнего байта (TTL, TC избыточны в пакетных метках)
  3. Устранить необходимость в транзитной полезной нагрузке MPLS для транзитной печати P (сегодня выходит из строя ECMP)
  4. Расширяется за счет дизайна (этикетки специального назначения вводят огромную стоимость в байтах)
  5. Увеличенное пространство надписи
  6. Сосуществование с MPLSv1
ytti
источник