Лабораторная работа по BGP

Давайте настроим BGP на наших железках. Сейчас у нас на роутерах есть конфигурация OSPF, и она нам не очень сильно будет интересна. Дело в том, что мы сейчас хотим обмениваться маршрутами через BGP. Для того чтобы посмотреть, как у нас OSPF настроен, я делаю show ip ospf interfaces. Смотрю, что у нас тут есть. Интерфейс бриф. И я вижу, что наши роутеры OSPF дружат через virtual link и через туннельный интерфейс. Virtual link нас не интересует, а вот туннельный интерфейс нас интересует очень сильно. Давайте выключим туннельный интерфейс и сделаем вид, что у нас связи через OSPF, через туннельный интерфейс нет. У меня настройка туннельного интерфейса содержит в себе команду...

Или не содержит. IP OSPF network. Не содержит. Я его включил как-то иначе. Я делаю show run section router OSPF. Router OSPF network. Вот она. Да, команда network указывает на то, что я включаю OSPF на туннельном интерфейсе с помощью именно неё. Меня это не устраивает. Я хочу на туннельном интерфейсе OSPF выключить. И я это делаю. Router OSPF 1. No network. Чего-то там. Тем самым я отключил соседство по туннельному линку. И на центральном роутере я сейчас целиком полностью OSPF прибью. No router OSPF 1. Связь отвалилась. Что в итоге получается?

У нас сейчас есть OSPF внутри нашего региона, внутри нашего блока. Но центральный роутер в OSPF не хочет с нами дружить. Поэтому дружба у нас тут особо не получается. И в do show ip route нам сейчас покажут, что маршрутов у нас здесь не очень много. Те маршруты, которые внутри нашего блока 15, моего блока, они здесь есть. Они показываются. Но маршрутов OSPF от внешних других комплектов у нас тут не видно. Это замечательно. Мы сейчас сделаем так, чтобы у нас эти комплекты появились по BGP. Что нам нужно сделать для того, чтобы стало хорошо? Нам нужно будет подружиться по BGP с центральным роутером. Если я правильно помню, у нас есть IP-шник 101.101.101.101. Давайте попробую. Do ping 101.101.101.101. И он даже пингуется. Это IP-шник центрального роутера.

И мы сейчас сделаем так, чтобы этот IP-шник у нас являлся точкой, с которой мы будем устанавливать соседские отношения. Если бы мы вдруг хотели подружиться по BGP по туннелю, мы бы могли это сделать. Там было бы всё очень просто. У нас туннельный интерфейс. Мы в нём непосредственно подключены друг к другу. Но я хочу продемонстрировать пример с eBGP Multihop, что нам нужно будет включить eBGP Multihop для того, чтобы эта штука заработала. Запускаем контекст BGP, router BGP. И нам нужно будет использовать номера автономных систем, которые будут у каждого свои. Я предлагаю использовать 65000 плюс номер комплекта. В моём случае 65015. У первого комплекта будет 65001, у второго 65002 и так далее. Вы не можете запустить два разных экземпляра router BGP. Если вы в OSPF скажете router OSPF 1, router OSPF 2, у вас запустится отдельный экземпляр.

RIP нельзя запустить больше чем в одном экземпляре, но у RIP нет никаких названий экземпляра. Вы просто его запускаете — router RIP. А у BGP, если вы его запустили с одним номером автономки, то с другим его запустить уже не получится. Система скажет: извините, BGP уже запущен с другим номером автономной системы. И после того, как мы прописали, что router BGP у нас есть, давайте пропишем neighbor 101.101.101.101. Remote AS 101. Не 101, а 65101. Мы указали, что у нас есть сосед, и сосед eBGP-шный. У нас номер автономки 65015, у него 65101 — это, очевидно, eBGP-шная связь. На центральном роутере нужно сделать ответные действия, и я должен буду понять, из-под какого IP-шника у нас сейчас устанавливается связь.

Давайте я сделаю вот как. Do debug IP ICMP. 101.101.101.101. Мне нужно знать IP-шник. И я вижу, что попытки подключения у нас идут из-под PPPoE-шных адресов, которые заранее неизвестны, и это, конечно, печально. Давайте тогда дружить по туннелю. Не знаю, насколько это хорошая идея, но ладно.

Мы прописываем, что у нас есть IP-шник соседа 101.101.101.101, и мы прописываем, что с этим соседом мы должны будем дружить с определённого адреса. Дело в том, что если мы сейчас не укажем, из-под какого IP-шника мы будем отправлять наши пакеты, это приведёт к тому, что отправлять мы их будем с того адреса, который висит на интерфейсе, с которого уходят пакеты. Сейчас пакеты уходят с PPPoE-шного интерфейса, где у нас висит случайный непредсказуемый IP-шник. Если я буду отправлять пакеты со случайного непредсказуемого IP-шника на центральный роутер, то я не смогу там прописать указание, что определённый IP-шник определённого соседа смотрит в определённую автономную систему. Мне нужно, чтобы каждый пакет, который мы отправляем, уходил бы со вполне определённого IP-адреса, и чтобы на центральном роутере можно было бы прописать соответствие IP-шника и автономной системы. Поэтому мы указываем, что у нас neighbor 101.101.101.101 идёт с update-source Tunnel0.

Это не заставит пакеты отправляться через туннельный интерфейс, это заставит пакеты отправляться с IP-шником источника туннельного интерфейса, но физически они, конечно же, будут идти по PPPoE. Зато это позволит мне на центральном роутере знать, какие IP-шники могут быть в качестве адреса источника и к каким автономным системам они будут привязываться. Поэтому сейчас я прописал remote-as, я прописал update-source, и я на центральном роутере прописываю ответные действия. Router BGP 65101. Neighbor 192.168.0.1. Remote-as 65001. Дальше двойка. Тройка. Четвёрка. Пятёрка. Это, конечно, не очень быстрое дело, но нам никто не обещал, что в BGP всё будет быстро.

Восьмёрка. Девятка. Десятка. Одиннадцать. Промахнулся. Одиннадцать. Двенадцать. Дело близится к концу. Тринадцать. Тринадцать, по-моему, нет. На всякий случай сделаю. И пятнадцать. Я прописал пятнадцать нейборов, прописал им всем remote-as. Чтобы стало хорошо, нужно, чтобы пакеты, которые центральный роутер отправляет, шли из-под IP-шника интерфейса 101.101.101.101. Если я сейчас заставлю себя на каждого нейбора отдельно прописывать update-source, я дуба дам. Поэтому я сейчас скажу, что все эти нейборы будут входить в peer-group.

И я создаю peer-group. Neighbor eBGP peer-group. И я прописываю, что в этой peer-group у нас есть update-source Loopback 1.1. Do show IP interface. На всякий случай проверяю. Да, это тот самый интерфейс, на котором висит IP-шник 101.101.101.101. Создал peer-group. Прописал update-source Loopback 101. И теперь вешаю эту peer-group на каждого из соседей. Здесь уже ничего не сделаешь, придётся это сделать. Neighbor один — peer-group eBGP. То же самое на каждого соседа. Сейчас прописываю. Если вам кажется, что это такое же количество калорий придётся потратить, что и на каждого соседа отдельно прописать update-source, то на самом деле я просто немножко дальше знаю, в чём у нас будут сложности.

И я догадываюсь, что нам придётся ещё кое-какие команды на этих соседей прописывать. Обращаю внимание, что уже поднялась связь с четвёртым комплектом. Какой-то он шустрый. 10, 11, 12, 13. Дело близится к концу. 14 и 15. Если вы думаете, что подозрительно, что четвёртый поднялся, а все остальные нет, включая, кстати, и мой 15-й комплект, то вы абсолютно правильно делаете. Дело в том, что если мы дружим по адресам, которые не являются directly connected, то есть они не находятся в одной сети, а у нас, очевидно, адреса 192.168.0.1 и 101.101.101.1 не находятся в одной сети, то нам нужно использовать eBGP Multihop. И я сейчас должен буду на обеих сторонах прописать eBGP Multihop для того, чтобы пакеты, которые отправлялись к каждому из наших роутеров, отправлялись бы с правильными TTL.

Более того, на самом деле это больше нужно прописать именно на маленьких роутерах, на наших роутерах R1, потому что эти IP-шники центральный роутер может достать за одну копеечку TTL. Я чувствую, что пятый роутер уже у себя eBGP Multihop прописал. Давайте я тоже пропишу, чтобы, если вдруг вы не знаете, как это сделать: neighbor 101.101.101.101 прописываем eBGP Multihop. Можно ничего не указывать, просто нажать Enter, и тогда вы будете отправлять с TTL 255, то есть полностью отключаете ограничение eBGP Multihop, либо вы можете сказать eBGP Multihop 2. С каким именно TTL отправлять — будет достаточно, если вы пропишете двойку. После того как мы это сделали, соседство у нас должно подняться. Первый наш маленький роутер в сторону Core отправляет пакет с TTL двойкой. Они проходят через физический интерфейс, там вычитается копеечка, пакет направляется на движок маршрутизации, там определяется, что это наш собственный интерфейс, пакет обрабатывается процессором, и обратные ответы идут на туннельный интерфейс, и там достаточно всего одного прыжка.

Оно доходит напрямую на туннельный интерфейс. Но если бы мы дружили по loopback-ам, то нужно было бы ответные действия и со стороны центрального роутера тоже прописать. Я бы на peer-group, где у нас eBGP peer-group, update-source, я бы должен был там же прописать и eBGP Multihop 2. Сейчас это ни на что не повлияет, но гипотетически в определённых ситуациях это повлиять бы могло. Поэтому команда выглядела бы вот так. И получается, что я на каждого соседа должен был прописать eBGP Multihop, я на каждого соседа должен был прописать update-source, и получается, что если бы я прописывал и remote-as, у которого у каждого разная, и update-source, и eBGP Multihop, то мне на каждого соседа нужно было бы сделать три команды. А сейчас я схалявил и на каждого соседа сделал только две команды. Если мне нужно будет на всех одновременно повесить одинаковые настройки, я просто добавлю команду в peer-group, и она у меня автоматом применится ко всем сразу.

Там у нас что-то происходит с туннелем, но, кажется, ничего страшного. Соседство поднялось, и мы можем посмотреть, что в этом соседстве у нас образовалось. Базово проверим, что оно в established. Show IP BGP summary. Оно действительно established. У нас показывается краткая легенда, и у нас показывается, что есть сосед 101.101.101.101 в чужой относительно нас автономке, который с нами находится в состоянии established. Здесь циферка — значит, всё хорошо. Если вдруг вам хочется увидеть именно буквы established, то вы можете заказать show IP BGP neighbor 101.101.101.101. И здесь будет написано — вот оно, established. Но сейчас вам придётся ещё немножко помотать пробелом, потому что простыня, которая показывается на каждого соседа в show IP BGP neighbor, она достаточная для того, чтобы продиагностировать совершенно любую проблему, которая может произойти с соседом.

Поэтому раз экран, два экран, три экран, четыре экран, пять экран, шесть экран. Шесть экранов. Шесть экранов отборного диагностического материала. Если вам вдруг интересно, то вы можете его изучить. Но вообще там полезного не так много, что могло бы нам пригодиться. Из того, что стоит заметить: исходящий TTL у нас сейчас как раз два. Мы его eBGP Multihop задали. И у нас нет никаких ограничений на входящий TTL. Если бы мы вдруг включили TTL security, то мы бы сделали ограничение, что входящие пакеты должны иметь TTL какой-нибудь не меньше чем определённое значение. Давайте добавим какие-нибудь сетки в анонс. У нас сейчас в таблице маршрутизации есть как минимум сетки loopback-ов. Show IP route.

Где loopback? Вот. Connected IP-шник 10.15.1.1. И там сетка. В моём случае, обратите внимание, сетка 10.15.1.0 по 24-й маске. Можно брать только ту самую сетку, которая есть в таблице маршрутизации. Посмотрите, пожалуйста, какая у вас сетка висит на loopback-е, и какой IP-шник, и какая маска. И используйте, пожалуйста, именно её. Не получится вбросить то, чего в таблице маршрутизации нет. BGP — это distance-vector протокол, и при анонсе чего-нибудь у вас обязательно маршрут должен быть тот, который вы анонсируете. Команда network не позволяет создать автоматически пустой маршрут в никуда. Как мы это делаем при суммаризации в OSPF, в EIGRP, в RIP. Здесь ничего автоматически не создаётся. Вы всё должны сделать ручками. Если у вас нет такого маршрута, который вы хотите анонсировать, вы можете его придумать, создать статикой и потом анонсировать командой network. Но, опять же, всё ручками. Conf t. Я вижу, что на loopback-е у меня висит определённая сетка.

Я захожу в настройку router BGP 65015. И указываю команду network. Точно IP-шник, который у меня в таблице маршрутизации есть — 10.15.1.0. Слово mask. И точно маску, которая у меня в таблице маршрутизации есть. Сейчас такой маршрут забрался из таблицы маршрутизации в таблицу BGP. И дальше таблица BGP начинает реплицироваться между всеми роутерами. Отправился апдейт. Этот апдейт пробежал на центральный роутер. Центральный роутер отдал этот апдейт вам. Может быть, не сейчас, потому что BGP — неспешный протокол. А eBGP-шные соседства особенно неспешные. Поэтому анонсы, которые будут распространяться, они будут распространяться медленно. Задержка при eBGP-шном взаимодействии может быть в районе 30 секунд. Поэтому если я сейчас посмотрю, какие апдейты ко мне прибежали, совершенно не факт, что все ваши апдейты там будут. Show IP route.

Ну вот какие-то уже есть. 10.3.1.0, 4.1.0. Вот они, BGP-шные маршруты. Буквой B показаны. 3, 4, 5, 11, 12. И маршруты прибегают по eBGP-шной связи. eBGP-шные маршруты, которые добавлены в таблицу маршрутизации из-за того, что их eBGP-шный сосед прислал на ваш роутер, имеют административное расстояние 20. И это меньше, чем у любого другого протокола динамической маршрутизации. Потому что если к нам приходит маршрут eBGP-шный и к нам приходит маршрут любой другой, например, какой-нибудь OSPF-овский, это означает, что одна и та же сетка известна изначально где-то снаружи. Мы приняли такой маршрут, он прошёл через фильтры, поэтому мы действительно приняли какой-то внешний маршрут, который изначально зародился где-то ещё. И мы приняли этот маршрут по OSPF, а в OSPF мы его ниоткуда не могли взять, кроме как приняв его снаружи.

Опять же, где-то в другом месте мы провели редистрибуцию в OSPF, и к нам пришёл одновременно и eBGP-шный маршрут, и редистрибутированный LSA type 5 OSPF-овский маршрут. В этом случае мы говорим: нет смысла по нашей внутренней автономной системе гонять трафик до другого бордера и дальше там его выпускать наружу. Когда можно здесь выпустить трафик наружу. Какой смысл нагружать наш внутренний канал, если всё равно надо будет в итоге трафик отправить куда-то ещё? Административное расстояние EBGP-шных маршрутов будет заведомо лучше, чем у любого другого типа динамических маршрутов. Он 20. Круче только суммарка в EIGRP, которая по умолчанию имеет административное расстояние 5, ну и статика.

Здесь немножко интересное проявление. Вообще говоря, в нормальных сценариях здесь мы видим, что у нас EBGP-шные маршруты есть. У них NextHop должен быть тот, который совпадает с IP-шником, с которым мы ставим сессию. Это EBGP-шная связь, и по идее мы здесь должны были ожидать именно 101.101.101.101. Здесь BGP меня перехитрил, потому что роутер центральный получает все сессии из-под IP-шников 192.168.0.чего-то. Он говорит, эти все IP-шники находятся в одной сети, и как следствие надо схалявить и отправить им IP-шники друг друга, потому что они друг друга лучше видят. Зачем трафик они будут пытаться направлять через меня — пусть лучше сами на себя гоняют трафик. Это оптимизация в BGP, она такая есть, и из-за этого мы сейчас видим, что NextHop центральный роутер не поменял. В реальности можно, конечно, это поведение отключить и сказать, что центральный роутер должен проставлять маршруты своим NextHop.

Давайте попробую это сделать. Я не очень хорошо помню, как это делается, но у меня гипотеза есть, как это можно будет сделать. Опять же, на Neighbor EBGP, на peer-группу всё. Я сейчас пропишу. Давайте попробуем сначала NextHopSelf. И дальше do clear IP BGP звёздочка out. Перепослать все маршруты. И посмотрим, к чему это приведёт. Я ожидаю, что у нас таблица маршрутизации, маршруты должны получить NextHop всё-таки 192.168.0.чего-то. Да, вот они обновились. Вот такое поведение мы должны наблюдать по умолчанию. Если вы по EBGP дружите, то обычно так оно и происходит, что вы получаете маршруты с NextHop, из-под которого ставится на вас сессия. Если мы ставим сессию со 101.101.101.101, то сосед, который присылает нам такой маршрут, говорит: ходи на мой IP-шник 101.101.101.101 до этих сетей.

Дальше. После того, как мы получили какие-то EBGP-шные маршруты, давайте посмотрим, что они у нас в таблице топологии будут делать. Show IP BGP. И здесь видно будет, какие сетки мы получили в анонсах. По каждой сети показывается, добавлена ли эта сетка или нет в таблицу маршрутизации. Птичка показывает, что добавлена. Показывается NextHop. Это какой атрибут проставлен в маршруте. Показывается путь, который прошла автономка, в нашем случае. Да, все маршруты пришли из автономки 65.101. И дальше они пришли туда откуда-то ещё. 65.001, 0.03, 0.04, 0.05, 0.11, 0.12. И буковка I означает, что этот маршрут изначально зародился внутри той автономки. И с ним всё в порядке.

Он просто был переложен в BGP естественным образом. С помощью команды Network. Маршрут 10.15.1.0 имеет NextHop 0.0.0.0, потому что этот маршрут придумал сам роутер R1. Давайте теперь попробуем поднять на R2 BGP и попробуем подружить R1 и R2 по IBGP-шной связи. Что у нас с лупбэками? Do show IP route. Есть ли у нас лупбэк второго роутера? Нам он определённо интересен. Лупбэк я не вижу. Давайте тогда так дружить. В принципе, в OSPF IBGP-шном не является прямо обязательнейшим требованием дружить по лупбэкам.

Это просто абсолютно стандартная практика, когда вы дружите по лупбэкам. Просто здесь я что-то не вижу в таблице маршрута, именно полученного по OSPF с лупбэком соседа. Давайте его выанонсируем в конце концов. Что, нам сложно, что ли? На R2, может, он есть? Нет? Mable, show IP route. Здесь есть маршрут до лупбэка, а здесь нет. Давайте добавим. Show IP route. Убедитесь, пожалуйста, что на каждом роутере у вас есть анонсированный IP-шник лупбэка. OSPF 1. 10.15.1. Любым способом сделайте так, чтобы лупбэки пингались на каждом из роутеров.

Я вижу, что у меня есть, например, OSPFv3, который дружит с OSPFv3 на роутере R1. Я сейчас сделаю: conf t, интерфейс loopback 0, OSPFv3 1, IPv4, area 0. И то же самое сделаю на R1. Интерфейс loopback 0, OSPFv3 1, IPv4, area 0. Моя задача сделать так, чтобы на обоих роутерах пингались лупбэки друг друга. Чтобы если я вдруг сделал что-то типа ping 10.15.2.2 source loopback 0, чтобы оно пингалось.

В моём случае оно пингается. Мне не важно как. Если вдруг у вас нет OSPF, вы его снесли, что-то ещё случилось — пропишите статикой. Нам сейчас не важно, откуда возьмутся эти лупбэки. Главное, чтобы они были. И после того, как они у вас появляются, можно прописать соседство. Самый простой способ, если вдруг у вас этих лупбэков нет — прописать статику. Или посмотрите, какие протоколы динамической маршрутизации есть. Тот же самый OSPF. И включите в него адреса лупбэков. 10.номер_комплекта.1.1 на одном роутере. 2.2 на другом. И дальше прописываем BGP-шное соседство. Router BGP 65.0.15. Neighbor IP-шник 10.15.2.2. Remote AS. Какой у нас номер автономки? 65. Такой же номер, как у нас. И, соответственно, update source.

И то же самое на другом роутере. Ответные действия. Router BGP 65.0.15. Neighbor 10.15.1.1. Remote AS. Такой же, как у нас. 65.0.15. И update source. Update source loopback 0. На самом деле, можно здесь видеть, что Neighbor поднялся даже до того, как я update source на втором роутере успел дописать. Это нормально. Дело в том, что на одном роутере прописано, что мы соединяемся с IP-шником 10.15.2.2. Из-под правильного лупбэка, и сессия ставится. Даже несмотря на то, что на ответном роутере мы не прописали update source. Потому что сессия уже поставилась. Она пришла из-под правильного IP-шника. Она пришла на правильный IP-шник. И новую сессию мы уже в ответ не ставим.

Если бы мы новую сессию ставили, мы бы тогда принимали во внимание команду update source loopback 0. Но BGP достаточно только одной сессии. Он не поднимает две сессии крест-накрест. А если вдруг он случайно поднимает две сессии крест-накрест, он одну из них всё равно прибьёт. В этой ситуации получается, что update source в принципе гипотетически достаточно прописать только с одной стороны. Но по факту лучше, конечно, прописывать с обеих. Мы видим, что сессия поднялась. Все настройки прописаны. И сейчас мы можем посмотреть show IP route BGP. И мы здесь будем надеяться, что у нас показываются все маршруты. Как же мы ошибаемся, да? Действительно. Связано это с тем, что в таблице BGP-шной все маршруты есть. Show IP BGP. Вот они. Но напротив каждого из них у нас стоит какая-то фигня. Во-первых, напротив большинства маршрутов в show IP BGP не показывается птичка.

Мы этот маршрут не смогли поставить в таблицу маршрутизации. В том числе и как раз потому, что у нас этот товарищ в таблице маршрутизации отсутствует. Мы не знаем, как добраться до IP-шника 101.101.101.101. На роутере первом атрибут NextHop не меняется. Ему присылается 101.101.101.101, и он дальше этот атрибут NextHop передаёт в неизменном виде. R2 не знает, как добраться до 101.101.101.101. Для того чтобы это поведение исправить, можно NextHopSelf прописать на роутере R1 в сторону R2. Или на peer-группе, если вы peer-группу делаете. Либо можно включить этот IP-шник в анонс условного того же OSPF. Любой способ, который вы захотите, будет подходить для того, чтобы нормально работать. А самый последний маршрут показывает, что у нас есть сетка 10.15.1.0/24, у которой NextHop роутера R1 самого. Он нам говорит: я сам придумал этот маршрут, пожалуйста, ходи через меня до этой сети.

Но этот маршрут не может быть добавлен в таблицу маршрутизации по очевиднейшей причине. Он там уже есть. И буковка R означает, что мы не смогли добавить маршрут в таблицу маршрутизации — RIB failure, потому что там что-то сказало, что я маршрут этот принимать не буду прямо активно. Не просто мы не можем его добавить, потому что маршрут кривой. А там уже занято. И в таблице маршрутизации show IP route 10.15.1.0 мы видим, что маршрут есть, маршрут OSPF, административное расстояние у него 110. А маршрут в BGP мы получаем от IBGP-шного соседа. И административное расстояние IBGP будет 200. Хуже, чем любой другой способ добраться до внутренней сети. Если к нам приходит маршрут внутри IBGP и одновременно по OSPF, мы говорим: этот маршрут известен от какого-то роутера внутри автономной системы.

И у нас есть вариант добраться внутри автономной системы по OSPF и по BGP. Какой способ нам выбрать, учитывая, что этот маршрут из своей собственной автономки пришёл фактически? Естественно, имеет смысл использовать не IBGP-шный маршрут, а OSPF-овский, EIGRP-шный, да даже RIP-овский. Потому что это всё протоколы, которые учитывают топологию сети. Так или иначе, в какой-то степени. OSPF учитывает её по-честному. EIGRP учитывает хотя бы bandwidth, delay. RIP хотя бы количество прыжков учитывает. BGP не учитывает ничего. Он просто говорит: я могу добраться. Мне кто-то анонсировал, значит, я буду пытаться через него ходить. Поэтому OSPF посчитал маршрут по-честному. BGP сказал: я кое-как могу добраться до этой сети. В такой ситуации таблица маршрутизации предпочитает OSPF. Его административное расстояние 110 против 200 у IBGP-шных маршрутов. Для того чтобы добавить все эти маршруты, кроме самого последнего, с которым всё безнадёжно,

в таблицу маршрутизации нам нужно будет поменять NextHop. И на роутере R1 я указываю команду neighbor 10.15.2.2 NextHopSelf. IBGP-шная связь работает быстро, маршрут обновляется почти сразу, поэтому в таблице BGP-шной мы почти сразу увидим изменения. Это довольно быстро произойдёт. Если хотим ускорить, опять же, команда Clear есть. Do clear IP BGP звёздочка out. Можно указать, кому мы хотим что перепослать. В нашей ситуации можно перепослать всё всем. И обновилось. NextHop у нас поменялся. Да, после того как NextHop поменялся, появилась заветная птичка. Вот она. Маршрут добавился в таблицу маршрутизации. И команда show IP BGP, пардон, show IP route BGP показывает, что маршруты BGP-шные есть.

Административное расстояние маршрутов, полученных от IBGP-шного соседа, 200. Даже несмотря на то, что он, в свою очередь, их получил по EBGP, но мы видим их по IBGP, поэтому административное расстояние у них 200. И NextHop тот, который в анонсе прибежал. 10.15.1.1. Если бы мы не меняли NextHop, давайте отменю это. Ctrl-A, no neighbor NextHop. Пересбрасываем маршруты. Видим, что они опять прибегают с кривым атрибутом. 101.101.101.101. И, как следствие, не добавляются в таблицу. Сейчас мы попытаемся альтернативный способ использовать и сделать так, чтобы маршрут 101.101.101.101 у нас всё-таки в таблице появился. Один из немножко забавных способов, но тем не менее гипотетически он возможен. Вы можете прямо в BGP вбросить 101.101.101.101. В принципе, это, конечно, некрасиво так делать,

но если вы наружу не покажете никому, что вы так сделали, то можно сделать вот как. Network. 101.101.101. Mask 255.255.255.255. Этот маршрут должен быть у вас в таблице. На роутере R1 такого маршрута нет. Это нюанс. Поэтому, если вдруг он у вас будет, то вы можете его таким образом вбросить. У нас сейчас этот способ не прокатит, потому что этого маршрута у нас в таблице нет. Если мы его попытаемся создать, у нас поломается соседство. Так делать не надо в нашем конкретном случае. Но в определённой ситуации вы можете маршрут в BGP вбросить, и все остальные IBGP-шные соседи увидят этот маршрут, придуманный вами, смогут добавить этот маршрут в таблицу, и после того, как они добавили этот маршрут, добавить все остальные маршруты через него. В нашей ситуации будет, наверное, правильнее сделать вот как.

Нам надо будет редистрибутнуть этот маршрут. Это, конечно, тяжело. Я хотел показать, что можно взять и маршрут перетащить в BGP, именно этот самый транзитный, но немножко замудрился с тем, что у нас через этот IP-шник, именно через этот IP-шник по 32-й маске BGP, это не connected маршрут. Если бы он был connected, мы бы могли сказать redistribute connected. А так у нас в таблице маршрутизации его нет, у нас вместо него есть дефолт. А дефолт редистрибутить не хочется. Я думаю, что вы можете мне поверить, что этот маршрут можно взять и,

например, вбросить в какой-нибудь условный OSPF. Если бы он у нас был connected, можно было просто на интерфейсе OSPF включить. Как минимум один способ работает. Это как раз NextHopSelf проставить. Мы видели, что он добавляется. Давайте тогда его и будем использовать. NextHopSelf. И сбрасываем маршруты. Прошу прощения за то, что идея была пойти альтернативным способом. В нашем случае этот способ не сработает. Маршруты прибегают. Show IP route BGP показывает, что они есть. Административное расстояние 200. Метрика 0. NextHop 10.15.1.1. Давайте приступим к следующей части марлезонского балета. Будем изучать эти маршруты. И здесь нам понадобится новая теория.