Настройка MPLS L3 VPN: часть 1

Ну что, ребят, у меня есть предложение. Я надеюсь, что более-менее с точки зрения теоретической здесь стала некоторая ясность. Сейчас мы с вами попробуем это дело настроить. Итак, у нас есть вот такая вот топология. У нас есть вот такая вот топология. Соответственно, марштизатор R11 и марштизатор R14, они символизируют красного заказчика. Марштизаторы R13 и R12, они символизируют зеленого заказчика. Соответственно, что мне потребуется? Мне потребуется создать BGP-сессию между марштизаторами R1 и R4. Это будет моя вот эта сессия.

И, соответственно, мне потребуется создать BGP-сессию между марштизаторами R2 и R3. Единственное, чтобы не плодить сущности, я буду использовать технологию, которая называется root reflector. И, в частности, в качестве root reflector для обмена вот такими VPN-овскими маршрутами, я выберу марштизатор R8. То есть марштизатор R8 будет наш раут reflector. Соответственно, BGP-сессию будет необходимо построить между марштизатором R1 и R8, между марштизатором R3 и R8, между марштизатором R2 и R8, и между марштизаторами R4 и R8. Вот таким вот образом будет выглядеть наша первоначальная BGP-топология. Реалт reflector. Окей. Везде у меня будет работать...

Артур, раут reflector нужен для того, чтобы не строить полносвязную IBGP-топологию внутри одной автономной системы. Он позволяет уменьшить количество IBGP-сессий. Да. То есть конкретно в нашей топологии мы могли бы без него обойтись, но исключительно для немножко упрощения конфигурации, чтобы у меня была некая единая точка контроля при необходимости, но я заиспользую раут reflector. Плюс наличие рута рефлектора, как вы увидите позже, упростит нам жизнь, когда мы будем работать с построением IBGP-ов между разными автономными системами. Итак, поднимаем раутер IBGP-100. Смотрите. Помните, мы когда с вами делали первоначальный темплейт? We'll show run, section.bgp.

То есть мы создали связность между первым и вторым маршрутизатором, и мы обмениваемся IPv4 маршрутами. Смотрите, эта сессия нам больше не нужна. Удаляем. Прописываем нейбро амортизатор R8. Neighbor 150.888. Remote S. Remote S. Далее. Я обязательно должен указать update source. Есть некое требование, которое связано, скажем так, с тем, как цисточные маршрутизаторы генерируют метки и как они их обрабатывают с точки зрения дата плейна.

VPN-сессия между маршрутизаторами обязательно должна строиться с интерфейса, у которого сетевая маска равна 32 бита. То есть в нашем случае это обязательно должен быть лоббак. Update source. Лоббак. Сделано. Далее. Я муртизатору должен указать, что я хочу обмениваться с муртизатором R8 нашими VPN-секими маршрутами, которые состоят из префикса плюс наша root destination. Для этого мы поднимаем сессию в рамках адресного семейства address family VPN V4. Обмен VPN маршрутов. Говорим. Neighbor 150.888. Activate.

Show run section BGP. Итак, прописали neighbor, указали, с какого интерфейса строим нашу сессию, соответственно, какой интерфейс будем поставлять в качестве насхопа, и активировали адресное семейство. То есть активировали обмен маршрутами VPN. Обратите внимание, что современные версии IOS автоматически добавляют команду send community extender. то есть это как раз нужно для того, чтобы муртизатор отсылал в сторону соседа эти route target. В каких-то старых версиях IOS эта команда может по умолчанию не включаться. Соответственно, мне нужно ввести эту команду на муртизаторе R1. Далее. Ее нужно ввести на муртизаторе R2. Единственное, нужно будет изменить route 1.

Далее. На муртизаторах R3 и на муртизаторах R4. Для муртизатора R4. Если мы не дадим команду activate, то BGP-сессия для обмена VPN V4 маршрутами не поднимется. У вас BGP просто будет в состоянии…

Я не помню, как оно конкретно называется. Булат, извините. Что подразумевается под форматом записи? Я пока буду конфигурировать муртизатор R8. На муртизаторе R8. На муртизаторе R8. Формат записи root-design-short target обычно принято брать по маске. PELUPEC VPN V4 маршрут. Это может быть либо IP-адрес PELUPEC-муртизатора, либо что наиболее часто встречается номер автономной системы. То есть вместо PELUPEC, то, что написал, очень часто используется номер BGP-процесса. Так, первый, второй, третий, четвертый.

Если поднимаем сессию с первым, вторым, третьим, и с четвертым. Третий. Это будет первый, второй, третий, четвертый. Это будет второй. Это будет третий. Это будет четвертый. Что я забыл указать на амортизаторе? Вот это будет конфигурация нашего root-рефлектора. Я не указал, что эти амортизаторы будут являться нашими root-рефлектор-клиентами.

Обратите внимание, что они будут являться root-рефлектор-клиентами только для обмена VPN-V4 префиксами. То есть если вы будете обмениваться префиксами регулярного интернета, например, либо префиксами VPN-V6, либо IPv6, у вас роль root-рефлектора сервера может спокойно находиться на другом амортизатом. То есть это понятие, которое специфично для конкретного адресного семейства. Подождем, пока все сессии поднимутся. Обратите внимание, что сейчас, если я дам команду, которая почти всем из вас привычна, showipbgp summary, эта команда мне не покажет ничего. Почему? Дело в том, что команда showipbgp summary равносильна команде, более правильной команде.

showbgp, ipv4, unicast, summary. То есть она показывает установленные BGP-сессии, которые нужны для обмена IPv4 маршрутами. Но мы с вами IPv4 маршрутами обмениваться не собираемся, только VPN-V4. Поэтому что делаем? Чтобы посмотреть установленные VPN-V4-сессии, говорим showbgp. Далее конкретизируем, какое адресное семейство нас интересует. VPN-V4, unicast, all summary. Вречь внимание, что у меня есть 4 соседа. Все так же и планировалось. И от каждого из них мы пока получаем по 0 префикс. Но на самом деле это не удовлетворено. На этом не удовлетворено. Далее. Далее. Создаем VRF на маршрутизаторе R1. На маршрутизаторе R1.

VRF создается командой. Либо ее можно создать командой IPvRF и дать ее просто некое имя IPvRF. Это первый. Это первый вариант. Второй вариант. Второй вариант. Более такой, более современный. Есть команда, которая называется VRF definition. VRF definition. Далее. Мы говорим, для каких маршрутов эта VRF будет активна. У нас есть выбор. У нас есть выбор. Это может быть либо IPv4 маршрута, либо IPv6. Условно говоря, мы активируем работу данной VRF для IPv4 маршрута. Для IPv4 маршрута.

Здесь же задаем раут-таргеты. Обратите внимание, что мы можем задать раут-таргет на экспорт. То есть мы говорим, когда маршрут будет помещаться из VRF в BGP таблицу, к нему будет навешиваться вот этот раут-таргет. Импорт нам говорит следующее. Если мы принимаем VPNv4 BGP update и в нем содержится раут-таргет, который мы указали командой импорт, то мы его будем импортировать в нашу VRF. Можно указать сразу командочку BOSS. Командочку BOSS. То есть, по сути, это будет одно и то же значение для экспорта и для импорта. Давайте для красной VRF укажем раут-таргет. Экспорт 101. Обратите внимание, VRF red doesn't have a route-distinguisher конфиг.

То есть первое, что я должен сконфигурировать для любой VRF, это параметр route-distinguisher. Далее говорим, адрес-family IPO4, route-target-export 101, route-target-import 101. Стой. Далее, далее. Я должен вот этот интерфейсик, видите, у меня интерфейсик G3, я его должен поместить внутрь красный, только что созданный VRF. Как я это делаю? Я захожу в режим конфигурации интерфейса и говорю команду VRF forwarding и указываю имя VRF red. Обратите внимание, что по факту я выдергиваю интерфейс

из его дефолтного места, то есть из глобального мошетизатора и вставляю его внутрь красного мошетизатора. При этом сбрасываются его IP-адреса. Вдушу, run, интерфейс G3. Видите, здесь нет IP-адреса. И прописываю его здесь. Мошет. Теперь, если я скажу команду showiproute, showiproute connected, обратите внимание, что здесь нет сети, в которых характеризуется интерфейс G3. Почему? Потому что когда я даю команду showiproute без каких-либо ключевых значений, я смотрю таблицу мошетизации нашего глобального мошетизатора. Но интерфейс G3 у нас теперь

лежит внутри красного мошетизатора. Поэтому, если я хочу посмотреть табличку мошетизации красного мошетизатора, я должен об этом явно операционной системе сообщить. Делается это следующая команда. showiproute. После этого, после этого, просто добавляется ключевое слово vrf и имя vrf. И обратите внимание, что у меня есть connected сеть, которая лежит за интерфейсом G3. Соответственно, точно так же вы будете поступать, когда будете верифицировать OSPF-ные маршруты, BGP-шные маршруты. Они все будут вам видны именно вот отсюда. Видны именно вот отсюда. Окей, хорошо. Соответственно, у меня есть связность, у меня есть префикс 10.1.11.0. Хорошо. Хорошо.

Далее, то же самое я сделаю на мошетизаторе R4. На мошетизаторе R4. У меня там есть интерфейс showrun, интерфейс G2.4.14. А у меня пока даже... А, у меня здесь интерфейс тоже G3. Все верно. Здесь небольшая ошибка на схеме. То есть, это интерфейс G3. Создаем VRF definition red. Опять же, ребят, имя VRF может быть любое. Имя VRF может быть любое. Root Distingisher он также может быть любым. Также может быть любым. Главное, да, чтобы он был уникальным в проделах и дал мошетизатор. Далее, активируем адресное семейство IPv4

и назначаем route-target. RouteTarget, например, boss 101. showrun interface G3. Говорим, интерфейс G3. VRF forwarding red. И прописываем IP-адрес. Констант red. Так. Сделано. Сделано. Проверяем. show IP route G3. f right. Окей. Теперь, теперь, то есть, обратите внимание, что у меня мошетизатор R4 знает о локальных префиксах своего клиента, своего клиента. И мошетизатор R1

знает о префиксах своего клиента. Префиксах своего клиента. Мне теперь нужно, чтобы мошетизаторы обменялись этими префиксами. То есть, как это сделать? Мне необходимо на мошетизаторе R1 поместить префикс из VRF внутрь BGP-таблички. Как я это могу сделать? Смотрите, поскольку вот этот маршрут, вот этот маршрут, да, он мне известен с точки зрения амортизации, как directly connected. Чтобы поместить его в BGP, я могу использовать два метода. ребят, какие? Какие у нас есть методы помещения префиксов BGP? Дроп. И Василий был первым. Да. То есть, мы можем либо пойти по пути redistribute

connected, либо мы можем прописать просто net. Давайте я сделаю на одном муштизаторе так, на другом муштизаторе так. В частности, в частности, router BGP-100. Ребят, к вам вопрос. К вам вопрос. Обратите внимание, что вот эта сеть, она находится в красном муштизаторе. Да, в красном муштизаторе. Поэтому команду network я где должен прописывать? То есть, я должен как-то системе сказать, что искать данный префикс внутри красной таблицы муштизации. Для этого в IOS существует конструкция, которая называется address family ipv4 vrf red. И, соответственно, здесь говорю команду network 10 1 11 0 маска 255 255

255 вуаля. Что произойдет на муштизаторе R4? Вуаля. То есть, смотрите, муштизатор R1 получается showbgp vpnv4 unicastol так, сейчас извиняюсь, я дверь закрою. как видим, муштизатор R1 поместил поместил вот этот префикс 10 1 11 0 внутрь своей vpnv4 таблички. При этом он к нему добавил route distinguish 100 2 1. я могу

посмотреть более детальную информацию о нем 10 1 11 0 slash 24 внимание, что в таком вот виде помещается префикс в bgp табличку. Как я вам рисовал. Сначала идет наш root distinguish после этого идет наш непосредственно ipv4 префикс. Указание vref таблицы с которой этот префикс был экспортирован. Экспортирован. И мы дополнительно к нему навесили extended community route target 102 точания. Виктор, нет, не должен. Нет, не должен. Чтобы сейчас времени не занимать, я так успеем. я покажу, что будет, если root distinguish у нас различаются. Я это покажу на примере

зеленой vref. На самом деле все очень просто. Когда маршизатор принимает на себя bgp update, он от него отрезает root distinguish который к нему пришел и навешивает тот, который сконфигурирован локально. То есть условно говоря, если бы на маршизаторе r4 root distinguish был бы другим, то вот здесь я бы увидел не 100 двоеточие 1, а там что-то еще. То, которое было бы сконфигурировано локально. Скажем так, желательно, чтобы он совпадал, но это исключительно для того, чтобы облегчить процессы верификации в сети и прочее. Сейчас мы смотрим вот этот вывод

этого префикса. Обратите внимание, что здесь есть какой-то mpls лейбл. Очень непонятно. То есть мы вроде бы смотрим bgp префиксы, а у нас получается еще вывод каких-то mpls меток. Причем обратите внимание, их может быть две. Видите? In, out, то есть на вход и на выход. При этом out у нас no label, а входная метка 37. То есть запомним это число, оно нам пригодится буквально через минутку, может быть через две. На amortizator R4 я хочу поместить его локальный префикс в таблицу amortizator. Говорим router bgp100 address family ipv4 rf red и говорим redistribute connected с vout connected. Проверяем нашу bgp

табличку show bgp dpnv4 unicast summary unicast all дает вот появился мой префикс 10 4 14 0 на amortizator R1 я могу также ожидать вот этот префикс он недоступен через amortizator R4 show ip route bgp show ip route 0 f red то есть соответственно мы обменялись мы обменялись маршрутами которые сидят в верайфе ребят вопрос к вам смогу ли я сейчас запустить пинг между маршрутизатором R11

и маршрутизатором R14 как думаете давайте попробуем на amortizator R14 вот смотрите последнее предложение от Василия ребят скажите пожалуйста есть ли из вас кто-то кто не согласен Василий говорит что на R14 интерфейс нужно запихнуть в верайф Иван не согласен Василий смотри какое дело смотри какое дело у нас получается у нас

есть пе маршрутизатор пе маршрутизатор вот он большой мы взяли какой-то интерфейс поместили внутрь красный верайф у нас есть це маршрутизатор вот вот этот интерфейс и вот так мы их соединили с точки зрения це маршрутизатора вот этот интерфейс он также остается продолжает жить в глобальной таблице маршрутизации почему потому что как я говорил понятие верайф оно локально на на устройство ��의 ответ да набирать 총 fully пред represented

по ст