MPLS Inter-AS L3 VPN Option C: часть 1

Опция C. С точки зрения использования ресурсов, это самая оптимальная взаимодействие, которую, наверное, можно придумать. В опции все на самом деле хорошо, за исключением одной вещи. У нас, как я сказал, на SBR нету VRAF, но мы вынуждены все префиксы на SBR держать в BGP-таблице. То есть SBR-муштизаторы должны быть довольно-таки ресурсоемкими с точки зрения памяти. Поэтому появилась, скажем так, одна идея. Как вы думаете, внутри сервис-провайдера какие маршрутизаторы в любом случае будут держать на себе все VPN-овские маршруты, которые есть у кастомеров, которые принадлежат данному провайдеру?

Смотрите, у нас есть какое-то количество PE-раутеров, например, 100. Но поскольку PE-раутеры, условно говоря, какой-то PE-раутер может терминировать на себе первые 10 VPN-ов, вторые 10 и так далее, то очевидно, что на PE-муштизаторах все VPN-овские маршруты держаться не будут. Вопрос, ребят, где в сети будут в любом случае все маршруты так или иначе собираться? Подсказка, PE-муштизаторы напрямую между собой пирятся или нет? Вот. Посмотрите, у нас в сети уже есть рут-рефлектора. На этих рут-рефлекторах в рамках каждой акциональной системы будут содержаться все VPN-маршруты всех подключенных заказчиков.

Окей. Поэтому идея в следующем. Поднять VPN V4-сессию рут-рефлекторами. То есть в нашем примере нам нужна будет BGP VPN V4-сессия между муштизатором R7 и R8. У нас поднимается вот здесь вот VPN-сессия. Окей. То есть топология получается вот такая логически. Логически. Соответственно, на маршрутизаторах ASBR держать VPN V4-сессию больше нет необходимости. Согласны? Да.

Однако, однако, встает один... Смотрите. Как мы будем строить BGP-сессию между R7 и R8? Нам нужна IP-связность. Правильно? Если я сейчас зайду на маршрутизатор R7... Например, скажу. Show IP-Route 158.888. Network Notentable. Ребята, вопрос. Могу ли я построить BGP-сессию между R7 и R8? Нет. Очевидно, что нет, да? Поэтому, да, вот вроде бы при решении одной задачи у нас появляется решение другой задачи.

Чтобы R8-рефлектора смогли запириться друг с другом. Очевидно, что у этого решения, на самом деле, у этой задачи может быть несколько решений. Я вам сейчас постараюсь продемонстрировать, ну, я не знаю, хотя бы несколько из них. Хотя бы несколько из них. Вариант номер один. Вариант номер один. То есть, исходные данные какие? У нас вот здесь крутится SPF. Здесь крутится SPF. Пусть это будет красный SPF. Сверху у нас крутится свой синий SPF. Синий SPF. Можно сделать что? Можно поднять вот здесь вот. SPF. Ну, например, там, либо EGRP, неважно. Что нужно будет сделать?

Заредистрибутировать маршруты из синего в зеленый. Заредистрибутировать маршруты из красного в зеленый. Ну, как минимум, лупбеки, которые нам нужны. Ну, и, очевидно, в обратном направлении. Из зеленого в синий и из зеленого в красный. Из зеленого в красный. Таким образом, таким образом, у нас может появиться связность между амортизаторами и R7 и R8. Но, но, но, в принципе, вариант рабочий. Вариант рабочий. Проблема в следующем. По сути, мы объединяем, ну, не то чтобы объединяем, как-то скрещиваем наши независимые IGP домены. Которые не должны перекрещиваться между двумя различными организациями.

Второй нюанс. Ребят, смотрите. Очевидно, да, что нам необходимо обеспечить, да, так или иначе распространение, ну, то есть, там, чтобы трафик с помощью меток ходил. Мы все равно добиваемся, пытаемся добиться того, чтобы транзитные железки, да, не видели кастомерских маршрутов. Но, соответственно, вот на этом линке, вот на этом линке, который живет между провайдерами, живет между провайдерами, здесь должен ходить какой-то интересный трафик. В частности, в частности, да, ну, если мы поднимаем IGP, обычно может использоваться технология обычного LDP. То есть, мы поднимаем с вами LDP-сессию. Эта LDP-сессия будет нам помогать передавать пакеты между нашими ASBR. В принципе, вариант рабочий. Но я не думаю, что мы с вами не будем его конфигурировать.

Есть второй вариант. Второй вариант, мне кажется, более интересный. В каком плане? Скажите, пожалуйста, скажите, пожалуйста, между R9 и R10, то есть, ну, в реальной жизни провайдеров, в любом случае, какой протокол муртизации будет работать? То есть, там, у СПФ, там, нужно, там, в любом случае, как-то дополнительно туда внедрять. Но ведь они же будут точно периться по БГП, правильно? Правильно. Мы поднимаем вот здесь. То есть, у нас здесь есть БГП-сессия. БГП-сессия. Встает. Далее. Что мы можем сделать? Мы можем на R10 сделать редистрибьюцию.

Например, из ОСПФа внутрь БГП. И здесь мы должны передать, будем маршрут нашего рут рефлектора. То есть, мы должны будем заредистрибутировать лупбэк муртизатора R7. То же самое, то же самое. Мы должны будем сделать на муртизаторе R9. То есть, мы должны будем вот так вот сделать. Сделать опять же редистрибуцию из ОСПФа в BGP. А здесь мы будем редистрибутировать лупбэк нашего муртизатора R8. Ну, очевидно, у нас будет обратная редистрибьюция из BGP в ОСПФ на каждом сайте. То есть, таким образом, мы сможем достичь того, что он... Рефлектора R7 и R8 увидят друг друга и смогут вот эту VPN-овскую сессию построить.

Встает вопрос, как передавать трафик между муртизаторами R9 и R10. Мы здесь не запускаем BGP, мы здесь не запускаем LDP. Вместо этого, вместо этого мы поднимаем вот этот пиринг BGP-шный в специальном, в дополнительном адресном семействе. Adress family, которое называется IPv4 labeled unicast. По сути, что это за адресное семейство? Когда муртизатор R10? Когда муртизатор R10? Передает какой-то префикс. Ребят, пожалуйста, вставайте на MUT. Пайлов... да, заметьте.

Нет. У вас мючу, он у вас размючивается. Когда муртизатор R10 передает префикс в сторону R9, то есть он передает префикс о муртизаторе R7. Он передает не только сам префикс, но плюс некую метку. Плюс некую метку. И, соответственно, эта метка будет использоваться муртизатором R9, когда пакет будет лететь в сторону R7. По сути, это будет на самом деле транспортная метка. Мы здесь просто заменяем LDP-метку на BGP-шную метку. Такой вариант. Это вариант с редистрибьюцией. Есть еще третий вариант. Есть еще третий вариант.

Абсолютно без редистрибьюции. Без редистрибьюции между различными протоколами. Что мы делаем? Что мы делаем? У нас какая-то полага получается. Очевидно, что у нас... Так, у нас получается... Я красным рисую VPN-овские сессии. У нас получается... VPN-сессия. Что мы можем еще сделать? Что мы еще можем сделать? Смотрите. Мы можем вот этот лукбэк... Мы можем лукбэк наш... Поместить внутрь BGP. То есть мы можем зайти в раутер BGP и сказать команду network. Далее. На маршрутизаторе R8 мы поднимаем BGP-сессию с маршрутизатором R9. В адресном семействе labeled IPA4.

Таким образом мы даем маршрутизатору R9... Метку BGP-шную для того, чтобы достигнуть амортизатора R8. Далее. Далее. Это мет... То есть дальше сессия начинает вот так тянуться. И таким образом, таким образом, трафик между рутер-рефлекторами сможет бегать посредством PLS-ных меток. То есть, соответственно, заказчик будет скрыт. Ребята, единственное, у меня к вам возникает такой вопрос. Окей. Предположим, что R9 теперь, чтобы достигнуть амортизатора R8, будет использовать, скажем, не LDP-шную метку, а вот эту, которую он получил по BGP.

Вопрос. Что будет с пакетом, когда он приближет на амортизатор R3? Амортизатор R3 что-нибудь знает об этой метке, которая была с помощью BGP сконфигурирована или нет? Он участвует в Labeled IPv4 пилинге? Нет. Поэтому, на самом деле, все транзитные амортизаторы, все транзитные амортизаторы у вас в автономке должны быть адресного семейства Label Typev4. Понятно? И еще один нюанс, который касается, скажем так, оптимизации. Смотрите, вот это VPN-овская сессия, которая строится между рут-рефлекторами.

Это IBGP, ребят, или IBGP? Ну же. Смелее. Очевидно, это IBGP. Что происходит с атрибутом NextHop, когда мы передаем IBGP-шный апдейт? Он подменяется на себя. То есть у нас для IBGP-сессии по умолчанию команда IBGP NextHopSell. NextHopSell. К чему это приводит? К чему это приводит? Это приводит, на самом деле, к одной такой очень неприятной вещи. Амортизатор R8 будет знать префикс, который...

То есть он будет знать о префиксе. Амортизатор R8 будет знать, что он мортизатор R12. Доступен через кого? К чему это? К чему это? К чему это? К чему это? К чему это? К чему это? Соответственно, он будет... То есть у него NextHop будет R8. Соответственно, в MPLS пакете будет ставиться метка IBGP-шная, которая характеризует амортизатор R8. Ребят, как у нас полетит пакет на DataPlan? То есть у нас пакет... Пролетит, пролетит, пролетит. Дальше на амортизатор R4 он попадает. На амортизатор R4 он попадает. Представьте себе, что у нас нет вот этого линка. Нет этого линка. Соответственно, поскольку метка характеризует амортизатор R7, то пакет, очевидно, посредством просто MPLS свитчинга,

добежит до амортизатора R7. Далее амортизатор R7 увидит, что у него есть метка, которая была получена от амортизатора R2. Свопнет ее и отправит трафик в сторону амортизатора R2 и дальше в сторону заказчика. Таким образом у вас появляется некая... Нужно понимать, что это не бесконечная петля. Это просто петля, которая приводит к неоптимальному раутингу. Поскольку у нас при IBGP-сессии между рут-рефлекторами BGP поднимает... BGP... NextHop... NextHop подменяется на адрес того амортизатора, который этот BGP апдейт отправляет, то амортизатор, который этот апдейт принял, будет использовать метку, которая характерна для NextHop.

Поэтому метка будет характеризовать именно рут-рефлектор. Таким образом пакет у нас по MPLS достигает рут-рефлектора. А рут-рефлектора на самом деле очень часто вообще могут где-то в стороне сети, то есть где-то там в стороне стоять какие-то отдельные сервера, например. Дальше пакет до рут-рефлектора добегает. Дальше подменяется... Чтобы такого не было, чтобы такого не было, для VPN v4 сессии между рут-рефлекторами обычно ставится команда NextHop unchanged. NextHop unchanged. То есть, соответственно, амортизатор R1, когда получит префик, когда получит BGP-шный апдейт, он будет видеть, что ему удаленная кастомерская сеть

видна за каким амортизатором? За амортизатором R2, то есть за выходным PE. То есть, по сути, у нас эмулируется прямая VPN v4 сессия между двумя PE-мортизаторами. К чему это приводит? Смотрите. Если мы используем BGP везде в системе, то есть BGP между провайдерами, то мы сначала должны построить BGP-labeled Unicast сессии. По этим сессиям мы должны отдавать лупбеки всех наших PE-мортизаторов. Плюс туда должен войти обязательно лупбек рут-рефлектора. Далее. Как только у вас поднялась вот эта IPv4-labeled Unicast сессия,

как только у вас поднялась лейбл Unicast сессия, у вас появляется возможность поднять VPN v4 сессию между рут-рефлекторами. То есть, по сути, у вас как бы у вас строится, у вас получится такая ситуация, что у вас строится BGP поверх BGP. Сначала построилась адрес BGP-сессия в рамках одного адресного семейства, и только после этого появляется возможность построить VPN-peering между ними. Я не знаю, ребят, как это для восприятия вот так вот сразу. Давайте попробуем рассмотреть на примере. Я надеюсь, что у нас с первого раза получится это дело тоже сконфигурировать, нигде не ошибиться. Нигде не ошибиться. Итак.

Давайте с вами начнем. Так, у нас партизатор R7 и R8 выступает в качестве рут-рефлекторов. Поэтому давайте с вами сразу и начнем с попытки построения BGP-сессии между ними. И так, мы говорим... BGP 24610, насколько я помню. Мы говорим Neighbor. Давайте я, чтобы у нас топология всегда была под рукой. И так. Далее. Далее. Нейбер. 150.8.8.8. Ремоута. С 1.3.5.7.9. Далее. Нейбер. 150.8.8.8. Ремоута. Ремоута. С 1.3.5.7.9.

Далее. Нейбер. Нейбер. 150.8.8.8. Упдейт. Сурс. Лупбек. 0. Далее. Говорим. Нейбер. 150.8.8.8. Не забываем, что нам нужно указать обязательно IBGP-мультихоп. Поскольку для IBGP-сессии по умолчанию тетейла выставляется равным единице. Здесь на тетейла равны единице. Очевидно, на нас не устроит. И в адресном семействе VPNV4 говорим Naibor. 150.8.8.8. Activate. Ну, не забываем. Не забываем сделать send community. Send community. И что я забыл дать? Я забыл дать команду next hop unchanged. Next hop unchanged.

То же самое я должен сделать на мышкизаторе R8. Автономка 1.359. Да. Со стеном. Не 1.3579. Наибор. 1.359. Другшим украинц. Собшим. Будет. 1.359. Да. И все остальное. Все остальное вроде бы осталось. Никуда не удалялось. Раутер BGP 1.359. Наибор. 150.7.7. Ремоут S2.4.6.10.

Говорим. Update Source. Loopback 0. BGP Multichop. Adress family. 4. Naibor 157.7.7. Активируем соседа. Выставляем next hop unchanged. And send comment. Send comment. Наверное там что-то. Send comment. Extend. Ну а сейчас show BGP. VPN 4. Unicast. All summary. Ничего не даст. Видите, состояние амортизатора находится. Состояние соседа. У нас idle. То есть, ну из-за того, что у нас просто еще нет маршрута. Да, для того, чтобы построить, скажем так, VPN 4.

Сессию к амортизотору R7. Амортизотору R7. Окей. Нам амортизотор R8. Showrun. Seng. Seng. Seng. Seng. Seng. Seng. Нам больше не нужен вот этот вот сайт. То есть, нам нужно будет на R8. Нам нужен будет пиринг только с первым и с седьмым. То есть, с девятым он уже не нужен. Router. 1, 2, 3, 5, 9. Adress family VPN V4. No neighbor activate. То же самое делаем на R7. Adress family VPN V4. No neighbor activate. Далее.

Нам необходимо адресное семейство labeled BGP V4 между рецидоторами внутри каждой автономной системы. То есть, опять же, мы с вами это сделаем в рамках… То есть, у нас также будет root reflector. Будет root reflector. Ну, те же самые муфтизаторы R7 и R8 будут выступать в качестве root reflector. Так, у нас получается на R8. На R8 мы пишем router BGP 1, 3, 5, 9. Говорим адрес family IPV4. Neighbor 150.1.1.1. Activate. Здесь мы добавляем ключевую команду.

Send label. То есть, именно вот эта команда активирует адресное семейство labeled Unicast. 10 1 3-мотая с 1 3 5 9 чтобы меня просто был шаблончик 0 и активы и у нас нейбор будет рут рефлектор клиентов вот рефлектор клан естественно такая же сессия мне потребуется с третьим третьем спят он из девятым

3 5 и здесь так секунду 1 3 1 3 5 9 5 5 получается

сделано просто пока что базово прописали соседей и нам не забываем о том что нам необходимо будет поместить свой лупбек ну в принципе лупбек мультизатора р1 нужен потому что это . терминации туннеля заговорим network 150 111 маск если не 1888 все это нам лупбек нужно будет для того чтобы потом построить vpnv4 дом на маршрутизатор р-8 с

и