Привет, незнакомец!

Похоже, вы здесь новенький. Чтобы принять участие, нажмите одну из кнопок ниже!

VPLS BGP Signalling (Kompella Mode). Label Block

отредактировано ноября 2016 Раздел: VPN
Это задача для коллективного разума.

Зачем в VPLS Kompella Mode нужен механизм автоматического вычисления меток?

Например, tLDP в Martini Mode высылает каждому своему соседу индивидуальную метку.
Почему бы не делать так и BGP?

В RFC ясным по белому написано:

Using a distinct BGP Update message to send a demultiplexor to each
remote PE would require the originating PE to send N such messages
for N remote PEs. The solution described in this document allows a
PE to send a single (common) Update message that contains
demultiplexors for all the remote PEs, instead of N individual
messages. Doing this reduces the control plane load both on the
originating PE as well as on the BGP Route Reflectors that may be
involved in distributing this Update to other PEs.

Но какая разница: отправляем мы несколько копий одного Update с Label Block или столько же разных сообщений, в которых передаётся конкретная метка без выпендрёжа?
Даже при использовании RR не очень очевиден выигрыш - только до RR идёт один пакет - дальше он всё-таки размножается. Могу только Inter-AS VPN сюда привязать - хоть как-то будет оправдано. И то трафик сейчас дешёвый, как и процессорное время.

И при этом такое решение влечёт за собой перерасход меток. Например у циски по умолчанию 10 меток в блоке. Если у меня 3 сайта, то 8 меток просто пропадают. А если я VE-ID ещё как попало раздам, вообще беда.
Пространство меток ограничено, напомню - обычно оно одно на все протоколы.

Есть версии?
Тэги темы:

Комментарии

  • Я конечно, все понимаю, но... назвать Kompella Compella...
    Это же человечище!!! :)
    пруф https://tools.ietf.org/html/rfc4761
  • По теме... о каком перерасходе меток идет речь? Там их миллион. И опять же, вам ведь ни кто не запрещает назначить site-range 1 и тогда вы получите желаемое поведение. 10 это конечно странно, учитывая, что Juniper позволяет на выбор 1,2,4,8,16 :)

    При большом количестве VPLS с большим количеством сайтов, можно добиться значительной экономии BGP префиксов и как следствие памяти, загрузки CPU и сходимости. Конечно для грозных Juniper MX и Cisco ASR это как семечки, но что вы скажете по поводу Mikrotik, например?
  • Этот механизм переехал из l2vpn, адаптировали под новую фичу.
  • gs1571 написал:


    При большом количестве VPLS с большим количеством сайтов, можно добиться значительной экономии BGP префиксов и как следствие памяти, загрузки CPU и сходимости. Конечно для грозных Juniper MX и Cisco ASR это как семечки, но что вы скажете по поводу Mikrotik, например?

    Если в результате для каждого соседа в каждом VSI PE всё равно вычисляет свою метку, откуда появляется экономия префиксов?
  • gs1571 написал:

    Я конечно, все понимаю, но... назвать Kompella Compella...

    Посыпаю голову пеплом. Исправил.
  • отредактировано октября 2016
    eucariot написал:

    gs1571 написал:


    При большом количестве VPLS с большим количеством сайтов, можно добиться значительной экономии BGP префиксов и как следствие памяти, загрузки CPU и сходимости. Конечно для грозных Juniper MX и Cisco ASR это как семечки, но что вы скажете по поводу Mikrotik, например?

    Если в результате для каждого соседа в каждом VSI PE всё равно вычисляет свою метку, откуда появляется экономия префиксов?
    Вычисление метки делается для того, что бы уменьшить количество префиксов, в идеале при наличии одного сайта на PE с подряд идущими номерами, получается заметная экономия.

    Например:
    В сети 16 сайтов по одному на PE. Номера идут подряд.

    Размер блока - 1. Каждый PE анонсит по 15 префиксов (очевидно не анонсится блок с меткой для самого себя). Суммарно получаем 15x16 = 240 префиксов
    Размер блока - 4. Каждый PE анонсит по 4 префикса. Суммарно получаем 4x16 = 64 префикса
    Размер блока - 8. Каждый PE анонсит по 2 префикса. Суммарно получаем 2x16 = 32 префикса
    Размер блока - 16. Каждый PE анонсит по 1 префиксу. Суммарно получаем 1x16 = 16 префиксов

    Вроде так будет.

    Очевидно, что если сайты будут нумероваться не последовательно, то все не так радужно получается, но тем не менее.
  • gs1571 написал:


    Вроде так будет.

    Очевидно, что если сайты будут нумероваться не последовательно, то все не так радужно получается, но тем не менее.

    Но на каждом PE для одного VSI будет не один префикс, ведь каждый сосед анонсирует не один и тот же блок - Label Base у всех будет разный. В итоге PE для 16 сайтов в VSI будет иметь 15 разных префиксов.
    Или я где-то не прав?
  • eucariot написал:

    gs1571 написал:


    Вроде так будет.

    Очевидно, что если сайты будут нумероваться не последовательно, то все не так радужно получается, но тем не менее.

    Но на каждом PE для одного VSI будет не один префикс, ведь каждый сосед анонсирует не один и тот же блок - Label Base у всех будет разный. В итоге PE для 16 сайтов в VSI будет иметь 15 разных префиксов.
    Или я где-то не прав?
    Каждый PE генерирует блок меток, где каждая метка будет использоваться удаленным сайтом для отправки трафика на этот PE, т.е. по этим меткам будет происходить mac learning в ядро. Если рассмотреть схему, где все сайты поместились в один блок, то одна метка из блока используется для посылки трафика PE самому себе, т.е. она не используется.
    Итого, из одного блока на 16 меток будет задействовано 15 меток, 15-тью другими PE.

    Но тут важный момент, site-id других PE должны попадать в этот блок иначе будет сгенерирован новый блок на 16 меток закрывающий не закрытые site-id и т.д.
  • gs1571 написал:


    Итого, из одного блока на 16 меток будет задействовано 15 меток, 15-тью другими PE.

    То есть, если я правильно понял, то внимание на количестве входящих меток - у нас не отдельная ожидается от каждого соседнего PE, а блок меток - как одна запись?

    Но это означает, что когда приходит кадр с PW, нужно просчитать, от какого соседа он пришёл, вместо того, чтобы просто сделать lookup в LFIB?
  • отредактировано октября 2016
    eucariot написал:

    gs1571 написал:


    Итого, из одного блока на 16 меток будет задействовано 15 меток, 15-тью другими PE.

    То есть, если я правильно понял, то внимание на количестве входящих меток - у нас не отдельная ожидается от каждого соседнего PE, а блок меток - как одна запись?

    Но это означает, что когда приходит кадр с PW, нужно просчитать, от какого соседа он пришёл, вместо того, чтобы просто сделать lookup в LFIB?
    Тут принцип немного извращенcкий, но понятный. PE анонсит блок меток, по которым потом поймет от кого пришел трафик, т.е. например:

    Для первого блока из 4-х меток:
    метка 1 - PW для транзита трафика на этот PE с сайта с site-id 1
    метка 2 - PW для транзита трафика на этот PE с сайта с site-id 2
    метка 3 - PW для транзита трафика на этот PE с сайта с site-id 3
    метка 4 - PW для транзита трафика на этот PE с сайта с site-id 4

    Если у PE настроен site-id 2, то вторая метка из блока означает PW сам на себя, что не имеет смысла и она не используется. При этом:

    Метка 1 - это трафик с сайта site-id 1
    Метка 3 - это трафик с сайта site-id 3
    Метка 4 - это трафик с сайта site-id 4

    Весь этот расчет делается сразу и соответствующим образом программируется LFIB.

    Если прилетел анонс сайта с site-id 5, то этот PE автоматически генерирует следующий блок меток для site-id с 5 по 8.
    Если прилетел анонс сайта с site-id 35, то PE генерирует блок с site-id с 33 до 36

    И т.д.

    Для отправки трафика делается аналогичная процедура расчета, но только используются блоки полученные от других PE. Из всех блоков полученных от конкретного PE выбирается одна метка соответствующая локальному site-id для отправки трафика на этот конкретный PE.
  • gs1571 написал:


    Тут принцип немного извращенcкий, но понятный. PE анонсит блок меток, по которым потом поймет от кого пришел трафик, т.е. например:

    Принцип вычисления меток мне понятен. Я не могу в своей голове уложить, какой выигрыш даёт механизм блоков меток. В LFIB всё равно хранятся конкретные метки - это же не IP-адреса, чтобы сразу диапазон записать, тем более для разных соседей. Количество BGP-Update сообщений незначительно уменьшается.
  • Я нашёл ответ. И он гораздо интереснее, чем префиксы.
    Ждите статью про L2VPN :)
  • А обещанного, как известно, сколько ждут?
  • jedi написал:

    А обещанного, как известно, сколько ждут?

    В этом году. Если не успею, то без видео.
Войдите или Зарегистрируйтесь чтобы комментировать.