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

У этой опции есть, к сожалению, есть свои преимущества и свои недостатки. Основным преимуществом является полная прозрачность, понятность. Это самая легкая технология, самое легкое, что можно было придумать. Довольно легкий трэблшутинг. Трэблшутинг каждый из двух провайдеров, если вдруг что-то не работает, может проводить независимо от второго провайда, поскольку они перятся между собой только в рамках ВРФ. Но, что делать, если у нас, например, заказчиков, то есть у нас не один заказчик, их становится много, скажем, появляется CE100. Вопрос к вам. Между АСБРами между АСБРами.

Ребят, сколько вам линков понадобится, если у вас 100 заказчиков на обоих провайдерах? А почему один? Вот как вы сможете, смотрите, вот у нас Василий, да, твой вопрос абсолютно правильно. То есть, ну почему нельзя, смотри, у нас же на наших АСБРах, на наших АСБРах, шоу-ран интерфейс ГИИ 2.910, то есть вот у нас наш саб-интерфейс, который относится к нужной ВРФ. То есть, у нас на самом деле нам нужно 100 интерфейсов между АСБРами,

да, чтобы сделать вот их по количеству заказчиков. У нас появляется много-много всяких там линков между АСБРами. Да, конечно, это физически-физически, это может быть один интерфейс, да, но это будет 100 логических интерфейсов. Соответственно, сколько, да, ну, виланайди согласовать обязательно. И, ребят, сколько БГП-сессий у вас будет между двумя железками держаться? Да, то есть у вас будет, то есть у вас будет БГП-сессия вот здесь вот, да, у вас будет БГП-сессия вот здесь вот, то есть для каждого БГП-сессия, да, то есть отдельный клиент, это второй минус, да, то есть огромные-огромные

проблемы с масштабированием, то есть много интерфейсов это раз, много БГП-пиров-два, то есть, соответственно, это огромная БГП-какая-то конфигурация, за которую нужно непонятно как следить еще. И третий нюанс, смотрите, поскольку мы на АСБРах, мы на АСБРах заводим ВРФ, ВРФ, то очевидно, что на этих АСБРах у нас появляются таблицы муртизации в этих ВРФ, да, то есть show ip route ВРФ red. То есть, смотрите, помните, мы когда об MPLs-е с вами говорили, какая основная идея была? То есть, чтобы таблица муртизации, да, держалась только на граничных ПЕ-устройствах, и чтобы на транзитных устройствах вот этой таблицы муртизации не было. А здесь у нас появляется такая вещь, что транзитные АСБРы будут знать всю таблицу муртизации для всех ВРФ. Для

всех ВРФ. Поэтому, поэтому есть некие, скажем так, есть некие способы, есть некие способы это дело, скажем так, оптимизировать. Оптимизировать. Это люди, некоторые умные люди думали-думали и додумались примерно вот до чего. Опция В. То есть, ребята, мы сегодня с вами только на самом деле начнем рассматривать, мы не успеем полностью рассмотреть, у нас времени осталось 15 минут. Продолжим уже завтра. Суть в чем? У нас есть АСБР1, у нас здесь есть АСБР2. У нас здесь есть P1,

P2. Здесь у нас есть какой-то рут-рефлектор в стороне. Здесь у нас есть P1. Здесь то же самое получается. P3, P4, здесь какой-то второй рут-рефлектор и здесь какой-то P2. P2. Предположим, что на этих PE-шках какое-то количество заказчиков. Основная идея опции B в следующем. мы поднимаем VPN V4 сессию. Соответственно, у нас VPN V4 сессия идет от PE к рут-рефлектору, от рут-рефлектора к АСБРу. VPN

V4. Вот эта сессия VPN V4. Далее. Здесь у нас все то же самое. Но между АСБРами поднимается IBGP VPN V4. IBGP VPN V4. Соответственно, по сути у нас появляется если рассматривается дело логически, у нас появляется по сути сквозная передача

префикса в рамках VPN V4 сессии между PE маршрутизаторами. То есть у нас появляется сквозной LSP от PE1 до PE2. То есть по сути что это значит? На самом деле это значит то, что у нас наша VPN метка будет оставаться постоянной на всем пути следования. Да, Василий? Мы таскаем VPN V4 метку от PE до PE. Основной нюанс следующий. смотрите я вам на самом деле не случайно показал дебаг. Давайте подумаем что у нас будет с

апдейтами. Смотрите, PE2 высылает апдейт на раут рефлектор. Поскольку это раут рефлектор он передает этот апдейт в сторону ASBR. Ребят, вопрос. Если мы не создаем на ASBR VRF у нас просто VPN V4 сессия без каких-либо VRF. Что ASBR сделает с префиксом вопрос так поставили. Если у него нет VRF настроенного, ему есть куда этот префикс импортировать? Да, нет. Правильно, нет. Ребят, что он с таким префиксом сделает?

Что мы в дебаге наблюдали? Дропнет. Да, конечно, дропнет. И наша вся затея с построением LSP уходит в небольшое небытие. Соответственно, в этом случае есть различные воркараунды. Скажем так, первый воркараунд самый плохой. Как вы думаете, какой можно сделать? Можно на SBR поднять какой-нибудь например, фейковый например, просто лупбэк, поместить этот лупбэк в VRF и для этой VRF сделать импорт нужного раут таргета.

Таким образом таким образом SBR сохранит на себе все VPN-овские префиксы и сможет передать его дальше уже по IBG. Сможет его передать дальше уже по IBG. Но это, наверное, не самый красивый вариант. Не самый красивый вариант. Можно сделать следующее. Если зайти на железку, на железку, в частности на Marsator R9, есть раутер BGP 1.3.5.9 BGP Default Route Target Filter Обратите внимание. Control Automatic VPN Route Target Filter. Как вы думаете, что будет, если я дам такую команду?

Есть какая-нибудь идея? На самом деле может логично у вас появиться из моего рассказа. по сути, по сути, если мы дадим вот эту команду, то маршетизатор, когда будет принимать префикс, он не будет смотреть, есть ли ему куда импортировать эти префиксы или нет. Он их всегда будет сохранять у себя VPN V4 таблица и дальше адвертайзить всем своим VPN V4 соседям. То есть, с одной стороны, мы сохраняем на ASBR все VPN префиксы, они будут храниться внутри BGP таблицы, но они не будут импортироваться

внутрь VRF, соответственно, они не будут попадать в routing table для данной VRF. данной VRF. Давайте с вами сделаем. Нам понадобится команда на R9 и нам понадобится команда на R10. Далее. Далее. Мне потребуется перебить настройку вот этих интерфейсов между R9 и R10. Поскольку интерфейс git 2910 это уже не нужен нам здесь уже VRF forwarding, да? No VRF definition то есть я вообще убиваю эту

VRF No VRF definition red interface git 2 90 10 0 Okay. Interface git 2 10 10 10 10 10 10 10 10 0 далее do show run section bgp здесь получается router bgp 2 4 6 10 я говорю что у меня есть neighbor 10 9 10 9 remote as 1 3 5 9 и для адресного семейства VPN v4 я говорю neighbor 10 9 10 9 activate neighbor

10 9 10 9 send community send community extended единственное видите у меня тут SPF прям поднялся поскольку я вернул в global routing мне здесь SPF не нужен то есть я скажу просто убью отношения состедства на этом линке видите LDP поднялся LDP мне здесь не нужен разные автономные системы я просто скажу passive интерфейс G2 910 соответственно у меня маршрутизатор перестанет рассылать hello SPF сообщение поэтому у меня упадет успев и как следствие упадет LDP и то же самое сделаем на R9 router SPF 1 passive interface G2 910 далее

router BGP 1 3 5 9 neighbor 10 9 10 10 remote IS 2 4 6 10 address family VPN 4 neighbor 10 9 10 10 activate send community окей обратите внимание у меня поднялся neighbor IS UP и автоматом IUS на этом интерфейсе showrun интерфейс G2 910 выдает команду mpls BGP forward то есть смотрите у нас на линке на линке между двумя сервис провайдерами дело в том что мы не можем там оставить native IP почему потому что как я говорил если мы оставляем native IP то у нас

автоматически когда пакет передается через этот интерфейс удаляется весь стек mpls метод а вот как мы рассмотрели в самом начале опции B наша задача сделать так чтобы VPN метка была end-to-end между двумя PEM ажтизаторами поэтому для передачи трафика между двумя BGP схопами у нас генерируется метка посредством протокола BGP эта команда EOS вводится автоматически тогда когда у нас на этом линке поднимается и BGP VPN V4 то есть посмотрите showbgp vpnv4 unicast summary unicast all summary видите у меня есть префикс 10 9 10 9 10 9 unicast all я получаю от него префикс

11 11 11 и вот она метка номер 36 соответственно смотрите если я сейчас запущу трассу единственное у меня здесь наверное сейчас пока ничего не заработает show IP route BGP хотя есть единственное на 12 наверное нет маршрута мне так кажется show show IP route BGP а нет есть trace route 11 11 11 11 source lookback 0 numeric ну видите к сожалению у меня здесь на самом деле пока что-то где-то не взлетело и как вы видите у меня next hop пропадает

я вижу только первый hop а дальше я теряю я не могу запустить на самом деле трассу внутренний пилособлок то есть похоже что видите у меня control plane работает то есть ping 12 12 12 12 source look 0 но но data plane data plane где-то поломан маршруты по BGP очень успешно распространяются но где-то у меня видимо снимаются меточки сейчас времени на это давайте тратить не будем будем потихонечку закругляться в начале следующего занятия мы с вами попытаемся отдебажить отдебажить то чего нам не хватает но идею я вам рассказал то есть это просто VPN V4 сессии

end-to-end то есть от PE до ASBR от ASBR к ASBR и от ASBR потом к PE вопросы какие есть ребят по сегодняшнему занятию и еще раз опция это просто некий метод, метод передачи информации. То есть это то, каким способом ты будешь распространять свою маршрутную информацию. Например, в опции А мы делали back-to-back V-Rave. То есть мы представляли, что второй провайдер

для нас является как бы заказчиком. В опции Б мы просто строим VPN V4 сессии между двумя ASBR. В опции С мы будем строить сессии как-то по-другому. То есть мы просто метки передаем различными путями с помощью различных протоколов. Ну что ж, ребят, если у нас вопросов больше нет, я предлагаю на этом заканчивать. Я вам желаю хорошего вечера. Отдыхайте. Завтра увидимся в то же время. Всего доброго.