BGP в Cisco IOS

Для того, чтобы BGP настроить в CISC, нам потребуется парочка команд. Там буквально действительно их немного. Для того, чтобы базовый BGP завелся, нам нужно будет каким-то образом указать, что у нас есть этот самый BGP, запустить процесс, указать номер автономной системы. Вы, наверное, уже догадываетесь, как это делается. Указываем роутер, BGP — всё по аналогии с предыдущими запусками, OSPF, RIP и так далее. И номер автономной системы. Вы указываете свой номер. После чего вы указываете в контексте роутера BGP свойства, с которыми он должен будет работать. Можете указать нейборов, например. Вы указываете нейбор, дальше айпишник соседа, remote AS и номер автономки соседа. На нейборы можно прописать много разных штук. Можно прописать update source, можно прописать EBGP Multihop, про которые сейчас буду говорить. Но самое важное, что должно быть на каждого соседа прописано,

это remote AS. Не надо прописывать все свойства, которые вам в справке будут выдаваться. В частности, не надо будет прописывать такую штуку, как local AS. Remote AS вы обязаны прописать. Все остальное опционально. К сожалению, в циске некоторые свойства, которые можно прописать на нейборы, называются не совсем говорящим образом. Но это не в первый раз мы такое встречаем. Ту же самую команду network в OSPF, к примеру, мы уже видели, которая делает совершенно не то, что вы от нее ожидаете. То же самое здесь. Neighbor Local AS — это не про то, что вы думаете. Не надо прописывать свою Local AS просто так. Remote AS, однако, прописывать вы обязаны. Без этого не заведется. Если вы хотите, вы можете прописать на нейбора update source, с какого адреса вы будете с ним дружить.

Нужно это будет в ситуации, когда вы дружите по лупбекам. Если у нас, например, есть роутер R1 и R2, и вы поднимаете лупбеки и связываетесь с соседом по лупбекам, то вам надо сказать — дружим с лупбеком из-под лупбека. Дальше. Что еще понадобится? Если мы хотим дружить с соседом внутри IBGP соседства, то там проблемы с TTL нет. Но если мы дружим по EBGP, и мы дружим, например, как раз по лупбекам, то нам, возможно, потребуется включить либо EBGP multi-hop, чтобы мы отправляли пакеты с TTL больше, чем единичка, либо включить BGP TTL Security и указать, в скольких хопах мы будем от получателя. Эти механизмы взаимоисключающие. В одном случае мы отправляем с TTL, какой скажем, TTL, например, 2. В другом случае мы отправляем пакеты всегда с TTL 255. В случае с EBGP multi-hop принимаем мы пакеты с любым TTL,

а в случае с BGP TTL Security мы в явном виде указываем, какой TTL должен быть у приходящих пакетов. Соответственно, либо мы прописываем neighbor чего-то там, EBGP multi-hop и дальше количество прыжков. Это на самом деле тот TTL, который у нас будет на отправку указываться. Либо мы включаем neighbor чего-то там, TTL Security, hops, и дальше в скольких прыжках мы находимся от соседа. По факту это влияет на то, с каким TTL мы согласны принимать пакеты. Отправляются они всегда с 255, но если мы находимся в двух прыжках, то принимать пакеты мы будем с TTL 254 или 253. Так, далее. После того, как мы включили в список соседей соседа с определенным IP-шником, указали, какой номер автономной системы у него будет, мы начинаем пытаться к нему подключаться. Если у соседа наш IP-шник прописан, то есть он согласен принять от нас сессию,

то мы поднимаем соседство. У нас пробегает сообщение, что BGP обнаружил нового neighbor, сосед перешел в established, и дальше можно посмотреть какие-то базовые BGP-шные свойства. Есть команда show ip bgp summary, которая покажет то, как у вас BGP работает, и среди прочего она покажет список соседей. Специальной команды, которая покажет только список соседей и больше ничего в BGP, в CISC нету, есть только show ip bgp summary. И вот нам показывается, что у нас роутер есть с номером автономки 64501, есть сосед 192.0.2.2, который находится в автономке 64502. И среди важного, что здесь нам нужно будет знать, последняя колонка будет показывать state/prefix received. Если мы видим там какие-то цифры, хотя бы даже 0, значит соседство установилось и перешло в фазу established. Если у нас там что-то отличное от цифр, какие-то буквы показываются, idle, active и прочее, значит с соседом не все в порядке.

Но в нашем случае мы видим здесь цифры, значит соседство established. Если мы хотим посмотреть детально, что с соседом, посмотреть его свойства, посмотреть, как он заявил о себе, то мы можем заказать детальное отображение с помощью команды show ip bgp neighbors и указать айпишник соседа. Это покажет простыню по каждому из соседей. Или если заказывать конкретный айпишник, только по конкретному соседу покажет простыню, покажет айпишник соседа, покажет номер автономки, сравнит номер автономки с нашим номером автономки. И если они совпадают, скажет internal link, если не совпадают, как в нашем случае, скажет external link. То есть это eBGP-шная связь. Дальше. Покажет router ID. У BGP, так же как у OSPF, так же как и у EIGRP, есть router ID. Он ему тоже нужен иногда. И здесь в нашем случае мы видим, что он какой-то там получился. Для BGP router ID не очень сильно полезен, но тем не менее он все равно назначается.

Если вы видите, что сосед у вас в фазе established, то значит с ним все хорошо. В нашем случае фазу established мы получили 20 секунд назад. И фактически даже можно считать, что с этого момента сессия установлена. Таймеры, которые у нас будут: как часто посылать keepalive — 60 секунд, как часто ожидать keepalive — hold time 180 секунд. Это как раз намек на то, что если мы в течение 180 секунд не получим ни одного keepalive, то мы заподозрим неладное. Мы скажем: мы-то свои keepalive отправляем, и нам на них приходят регулярно acknowledge, TCP-шные. Но BGP не посылает соседский keepalive, значит он завис. Значит там TCP-шная сессия висит, потому что ее поддерживает стек самого TCP, а вот сам процесс BGP у соседа имеет какие-то проблемы. Если у нас есть iBGP-шное соседство, то мы, как правило, его устанавливаем с loopback. Исключительно редко это будет происходить не по loopback.

Как правило, loopback все-таки используются. Эти loopback известны в OSPF, и, соответственно, мы говорим, что у нас есть своя автономная система, мы в ней запускаем OSPF, мы поднимаем здесь loopback, здесь loopback, мы эти loopback запихиваем в OSPF, и сессию устанавливаем из-под loopback. Следовательно, нам нужно прописать update source, и нам нужно прописать remote AS, сказав, что это именно iBGP-шная связь, что здесь не нужно проверять TTL, и вообще можно немножко расслабиться. Прописываем neighbor, IP-шник, remote AS, чего-то, neighbor IP-шник, update source, loopback 0. С iBGP-шным соседом те же самые команды по диагностике будут: show ip bgp summary и show ip bgp neighbors, конкретный IP-шник. В нашем случае show ip bgp summary показывает, что адрес соседа у нас есть, автономка соседа такая же, как у нас, это iBGP-шная связь, и сосед перешел в established. Если мы закажем show ip bgp neighbors, то мы увидим IP-шник соседа,

автономку соседа, internal link — совпадают номера автономки у нас и у него, и все в порядке. Мы проверили фазу established, означает, что сообщение how open criminal не обнаружено, мы знаем соседа в 64500 автономке, и он согласен с тем, что он в 64500 автономке. После того, как соседство установлено, нужно будет анонсировать какие-то сети. Как правило, если мы говорим про BGP, то это сценарий вида: у вас есть ваша автономка, у вас есть две автономки ваших провайдеров, вы хотите подключаться к каждой из них, и у вас есть, соответственно, роутер здесь и роутер здесь, и они, наверное, между собой даже как-то связаны. И вы хотите анонсировать свою внутреннюю сетку, которая у вас есть, в BGP, то есть это какие-то ваши собственные PI-IP-адреса. Эту сетку PI-адресов вы должны будете анонсировать своим пирам,

своим аплинкам, для того, чтобы они ее дальше анонсировали своим аплинкам, и чтобы все остальные узлы в интернете узнали о том, что у вас есть ваша собственная сетка. Команда network в BGP есть, и она ведет себя абсолютно не так, как себя вела в OSPF, как себя вела в RIP, как себя вела в EIGRP. Эта команда работает предсказуемым образом. В OSPF, в EIGRP и в RIP эта команда network действовала совершенно не так, как вы от нее ожидали. Она задавала условия access-листа, который отбирал IP-шники на интерфейсах, и если IP-шник на интерфейсе попадал под access-лист, то, соответственно, вы там на этом интерфейсе включали отправку пакетов и включали в анонс connected-сеть. В BGP нету включения просто BGP абстрактного на интерфейсе. У вас все соседи заранее известны. Connected-сети вы все подряд, в любом случае, не хотите отсылать. Но команда network делает следующую вещь. Вы указываете IP-шник и маску сети, которая у вас есть в таблице маршрутизации,

и которую вы хотите анонсировать своим соседям по BGP. Это фактически своего рода редистрибуция из таблицы маршрутизации одной сетки по вашему выбору. Вы указываете network, какую сетку забираем с какой маской. И для того, чтобы показать, что эта маска прямая, здесь есть слово mask, чтобы вы не путали эту штуку с OSPF или с EIGRP, где маска задается кривая в wildcard. Здесь прямая маска, и, соответственно, если такая сетка есть в таблице маршрутизации, то вы ее включаете в анонс BGP и рассказываете про нее своим соседям. Сказав на каком-то роутере, что у вас в таблице маршрутизации эта сетка есть, вы начинаете ее анонсировать. 203.0.113.0/24 здесь. И сюда тоже 203.0.113.0/24. Начинаете анонсировать ее здесь. Эта сетка уйдет сюда, эта сетка уйдет сюда, и роутеры в интернете будут думать,

как же они могут до вас добраться — через вот так или через вот так. Будут выбирать, какой из маршрутов до этой сети будет лучше с их точки зрения. Те роутеры, которые подключены, наверное, к первому провайдеру, они будут ходить вот так. Те роутеры, которые подключены ко второму провайдеру, будут ходить вот так. А те, кто находится где-то дальше, будут думать, какой вариант для них ближе. Где-то здесь, наверное, пойдут через одного провайдера, где-то тут — через другого. Это уже их дело, как они там будут выбирать лучшие маршруты. Вы должны своему провайдеру анонсировать вашу сетку. И как раз это удобно делать с помощью команды network. Это не единственный способ, как вы можете включить в анонс определенную сетку, но network просто проще всего. Указываете, какую сетку анонсировать, и она анонсируется. Если вы хотите посмотреть, что включено в анонс, что вы, скажем, отправили или получили при работе по BGP, то таблицу топологии BGP можно посмотреть с помощью команды show ip bgp. Здесь показывается некая легенда

и показываются маршруты, которые в BGP имеются. Здесь не столько маршруты, сколько префиксы. В нашем случае, когда у нас есть наша автономка, и мы анонсируем сетку свою командой network, и к нам приходит сетка от провайдера с дефолтным маршрутом, у нас в таблице топологии будет как раз два маршрута. Первый — присланный провайдером. Второй — который мы сами породили в таблице BGP и анонсируем нашему провайдеру. В этом случае команда network породила сетку 203.0.113.0. Next hop у такого самостоятельно придуманного именно на этом роутере маршрута будет 0.0.0.0. То есть в BGP next hop как такового нету. Но если вы сами начнете отсылать этот маршрут по eBGP-шному соседству, то вы себя пропишете в качестве next hop, и сосед весь трафик до этой сетки будет присылать вам. И в атрибуте AS Path — вот эта колонка, это атрибут AS Path —

у вас тут пустота. Маршрут зародился прямо внутри вашей автономки, и никакие другие автономки он не проходит. 0.0.0.0/0 — это маршрут, соответственно, до всех остальных сетей. Next hop — это вам провайдерский роутер прислал такой маршрут, он указан в качестве next hop. И маршрут этот зародился в автономке 64502. Соответственно, роутер провайдера, который вам прислал такой маршрут, добавил свою автономку в список AS Path, и вы понимаете, что маршрут зародился, после чего через 64502 автономку пришел к вам. Дальше. Если у нас есть EBGP соседство, то там с next hop все в порядке. При передаче по EBGP соседству next hop обновляется на IP-шник того, кто посылает. Но если у нас есть IBGP соседство, то есть у нас в пределах одной автономной системы роутер находится, там атрибуты никакие не меняются. И для того, чтобы вам можно было на IBGP-шных роутерах

поставить маршруты в таблицу маршрутизации, вам надо либо знать IP-шник next hop — как до него можно будет добраться, то есть вы должны будете его, например, в OSPF включить. И, соответственно, в этом случае, когда маршрут придет на R3, он скажет: «Я знаю, как добраться до IP-шника 10.0.0.1, я по OSPF сейчас посчитаю кратчайший путь до этой сети». Либо альтернативный вариант Вы можете воспользоваться специальной командой NextHopSelf Если вы отправляете по IBGP-соседству какие-то маршруты Вы перебиваете атрибут NextHop на себя По умолчанию эта штука выключена Но если вы хотите включить, вы указываете Neighbor 192.168.1.2 Частный IP-шник, который у нас здесь есть Роутер R3 И вы указываете NextHopSelf Раньше, до включения этой команды, на роутере R3 Маршрут до сетки 203.0.113.0/24 маски Этот маршрут, который по EBGP пришёл на R2

И дальше по IBGP переслался на R3 Раньше у него атрибут NextHop был 10.0.0.1 Этот IP-шник И R3 не знал, как до него добраться В таблице маршрутизации этот маршрут не устанавливался Потому что нельзя установить маршрут в таблице маршрутизации У которого NextHop не резолвится Здесь должна быть птичка Но её тут нету Поэтому маршрут не устанавливался Пользоваться им было нельзя Когда мы на роутере R2 Сказали на соседа Neighbor 192.168.1.2 NextHopSelf Соответственно, в таблице топологии У нас эта же сетка Стала известна с другим NextHop С 192.168.1.1 Из-под которого ставится сессия И, соответственно, в таблицу маршрутизации Такой маршрут мы уже добавить можем Птичка есть Вы можете использовать любой вариант Хотите — используете NextHopSelf Хотите — добавляете IP-шники в таблицу маршрутизации С использованием какого-то IGP-протокола

У обоих вариантов есть плюсы и минусы Какого-то универсального и стандартного способа нету Мне больше нравится вариант, при котором вы в таблицу маршрутизации добавляете Connected-сетки NextHop перебивать мне не очень нравится Но в определённых ситуациях проще перебить NextHop Если у вас есть соседство И вы прописали соседа Вы сказали, что у вас есть эти самые NextHop Иногда требуется пересогласовать маршруты с соседом Потому что BGP сам может переотправлять маршруты Которые вы каким-то образом модифицировали Например, атрибут NextHop взяли и поменяли Вам по умолчанию он ничего не отправляет Вы должны будете ему прописать волшебный пендель И этот волшебный пендель может быть одной из нескольких разновидностей по степени агрессивности Самый злой вариант — это переустановить соседство Вы отправляете notification и заново устанавливаете сессию

Эта штука называется hard reset Действительно, если вы по BGP отправляете notification, рвёте соседство То все маршруты, которые сосед вам прислал, естественно, становятся недействительны Если вдруг вы хотите разослать кому-то указание маршрута с новым NextHop Это может быть довольно неприятная вещь Потому что соседство может переустанавливаться в течение довольно долгого времени BGP — очень медленный протокол И если у вас есть BGP Full View, то есть роутер, у которого полная картинка интернета И он начинает на вас полную картинку интернета выливать Процесс переустановления соседства может занимать не то что минуты А в определённых очень негативных ситуациях он может занимать десятки минут и даже часы Если у вас слабенький роутер, старый роутер, они действительно Full View закачивали в течение часа Это было, конечно, исключительно редкое явление Но тем не менее сегодня мы, скорее всего, будем ограничиваться десятками минут Но тем не менее, пока у вас соседство не установлено, BGP сидит и курит бамбук

И, соответственно, маршруты в таблицу маршрутизации не ставятся до тех пор, пока у вас соседство полностью не прососётся Поэтому Hard Reset использовать — не очень хорошая идея В большинстве ситуаций, кроме как в лабораторных сценариях, Hard Reset использовать не нужно Что же стоит сделать, если вы породили какой-то маршрут, а потом подумали, что вы хотите переотправить этот маршрут уже с новыми атрибутами? Есть несколько вариантов того, что вам будет доступно Первый вариант — это так называемый Soft Reconfiguration механизм Он будет различаться в зависимости от того, хотите ли вы переотправить или переполучить маршруты Переотправить маршруты — это Soft Reconfiguration Out Вы просто их переотправляете Абсолютно нормальная вещь, не требует ничего специального, никакой поддержки со стороны получателя Вы просто говорите: переотправь, пожалуйста, маршруты Соседство при этом не рви Ничего не требуется от получателя, просто сессия висит, нормально работает

Вы какие-то маршруты переотправляете, те, которые изменились Как только они переотправились, сосед их обновит у себя в таблице Всё будет хорошо Soft Reconfiguration In — это штука старая, которая когда-то давным-давно решала проблему вида Нам сосед прислал какие-то маршруты Мы их приняли в табличку А потом мы захотели их немножко модифицировать Когда мы принимаем маршруты, мы их можем модифицировать с помощью route-map И мы прописали новую политику, и нам надо, чтобы он их переотправил В оригинальной версии BGP не было возможности сказать Переотправь мне маршруты Вы могли только порвать сессию И, соответственно, после того, как сосед переустанавливался Естественно, сосед вам всё перепосылал Оригинальная идея была в том, что вы могли отдельно в памяти Склонировать все сообщения, которые вам сосед присылал И если вдруг вам требовалось как бы переполучить все маршруты То вы из буфера, в который вы складывали все приходящие сообщения

Их передоставали И делали вид, что он вам прислал эти маршруты Хотя по факту он вам ничего не присылал Эта фича Soft Reconfiguration In Она требовала, чтобы вы выделили отдельную оперативку Под хранение от каждого соседа всего-всего-всего, что он вам посылал в неизменном виде Плюс, естественно, всё то, что он вам прислал Вы складывали в таблицу маршрутизации, в таблицу топологии Короче, память эта хрень требовала дофига Вы могли сохранить отдельно всё полученное от соседа И потом при необходимости переприменить политики Вы просто из закромов родины Делали вид, что вам это всё перепослали Хотя на самом деле всё это досталось из кэша Сегодня эта штука используется очень редко Потому что авторы протокола BGP Всё-таки поняли, что ненормально хранить в памяти все отдельные полученные сообщения И было бы прикольно, чтобы была возможность просто сказать Переотправь мне, пожалуйста, определённые маршруты Эта фича появилась позже Это дополнительное расширение, которое называется Route Refresh

Вы можете отправить сообщение Route Refresh И указать, какие маршруты вы просите переотправить И сосед вам переотправит эти маршруты Естественно Если у вас поддерживается Route Refresh То Soft Reconfiguration In вам особенно уже не нужен Потому что вы не должны будете хранить в памяти отдельно все сообщения, полученные от соседа Если вы можете в любой момент заставить его переотправить эти сообщения Пусть он их хранит Он всё равно их вынужден хранить как маршруты Так Сейчас, а здесь команды-то... Команды нет, что ли? Это fuck up Ладно Команда по сбросу соседства будет иметь вид Clear IP BGP Дальше вы указываете соседство Если хотите всех сбросить, указываете звёздочку И дальше указываете либо направление на сброс соседства Либо просто нажимаете Enter, если вы хотите сделать Hard Reset

Если вы хотите Soft Reconfiguration сделать, переотправить маршруты То вы указываете In или Out Ещё есть Soft In, Soft Out Вы можете просто указывать In или Out Это в большинстве ситуаций будет нормально работать Так Последнее, что хочется рассказать про базовый BGP в Cisco Это то, что в реальной сети у вас, скорее всего, будет очень похожая конфигурация у многих роутеров в топологии Если у вас есть реальная сеть, скорее всего, эта реальная сеть имеет вид какой-то вот такой Есть пара роутеров, которые находятся на границе Border Border 1, Border 2 У них есть какие-то аплинки И, соответственно, есть роутер, например, Distribution Router или что-то ещё И, соответственно, у вас вот так это всё дело выглядит

И вам нужно будет прописывать кучу-кучу-кучу роутеров в качестве соседей внутри сети Соответственно, получается, что у нас есть роутер Border 1, у которого есть два аплинка Аплинк первый, аплинк второй Есть четыре внутренних роутера Соответственно, раз внутренний, два внутренний, три внутренний, четыре внутренних роутера Было бы здорово, если бы мы на каждый отдельный внутренний роутер и на каждый отдельный аплинк Не прописывали все элементы конфигурации, которые были бы одинаковы Потому что одинаково, например, в случае с IBGP-соседствами будет то, что мы дружим из-под loopback-ов Что мы дружим с прописыванием NextHopSelf Мы дружим с соседями в одной и той же автономке На каждого соседа мы должны будем прописать Remote AS, Update Source, NextHopSelf Если пароли будем использовать, пароли будем прописывать Всякие политики, которые мы ещё пока с вами не проходили Но тем не менее их нужно прописывать Если у нас есть какие-то маршруты, которые мы отправляем соседям, надо указать, что мы отправляем

Если есть маршруты, которые мы принимаем от соседей, надо указать, что мы принимаем Для IBGP-соседей это в меньшей степени актуально Но для EBGP-соседей это очень актуально Мы должны будем указать, что мы с EBGP-соседями просто так не дружим Мы прописываем всякие EBGP-мультихопы Мы прописываем фильтрацию маршрутов на вход, фильтрацию маршрутов на выход Опять же, если аплинков много, то на каждого соседа всё придётся прописывать Для того чтобы немножко упростить конфигурацию В BGP придумали такую штуку, которая называется peer-group Смысл заключается в том, что вы делаете шаблон И в рамках этого шаблона вы говорите, какие настройки будут у всех роутеров, которые будут с этим шаблоном жить Например, у нас есть четыре внутренних роутера У них у всех одинаковая автономка У них у всех одинаково ставятся сессии из-под loopback-ов У них разные IP-шники, но тем не менее со всеми ними мы используем source-адрес на loopback нулевом

Со всеми ними мы используем NextHopSelf Со всеми ними мы используем пароль Эти настройки вы вешаете на так называемую peer-group, на шаблон И создаётся это командой neighbor, дальше название, не IP-шник, а название И ключевое слово peer-group После чего указываете neighbor, дальше то же самое название и те настройки, которые вы хотите применить ко всем узлам в рамках данного шаблона Remote AS, если вы по IBGP работаете Update Source, NextHopSelf, Password Тут парольная защита, понятно, что она делает Дальше вы говорите, что у вас есть 3, или 4, или 5, или 10 соседей, у которых одинаковые настройки Neighbor 10.0.2 peer-group IBGP Neighbor 10.0.3 peer-group IBGP и так далее И вместо того, чтобы на каждого соседа прописывать 4 разные команды, мы на соседа прописали одну команду, одну команду, одну команду Эта штука, соответственно, резко нам сэкономила место в конфиге

На EBGP-соседей то же самое У нас есть, например, типичные настройки, которые нужно для соседей делать Это повесить фильтр на вход и на выход Если у нас EBGP-соседство, мы не согласны принимать что попало и отправлять что попало Мы говорим, у нас есть EBGP-peer-group И шаблонная настройка будет в том, что мы прописываем фильтр на вход и фильтр на выход Route-map чего-то там вход-выход, понятно, что маршруты просто будут фильтроваться И, соответственно, указываем, что у нас есть IP-шник 10.1.1.1 И этот IP-шник должен получить настройки из шаблона EBGP Но в шаблоне не прописано, какой номер автономки будет Поэтому отдельно мы прописываем, что кроме шаблонных настроек Есть ещё нешаблонная настройка Remote AS 65100 И то же самое с другим соседом Мы должны были прописать на каждого соседа, возможно, три, четыре, пять, десять разных команд Тот же пароль повесить А вместо того, чтобы отдельно на каждого соседа прописывать

Мы это всё прописали в одном месте И по факту сэкономили место в конфиге У peer-group есть небольшие ограничения Нельзя одновременно одну и ту же peer-group использовать для EBGP-пиров и IBGP-пиров Это системное ограничение И связано оно с тем, что Cisco для EBGP-соседей и для IBGP-соседей Формирует по-разному анонсы Формирует по-разному маршруты Для EBGP-соседей у вас нужно перебивать NextHop Для IBGP-соседей, например, не нужно Поэтому в одну peer-group вы можете набить Либо только EBGP-соседей, либо только IBGP-соседей Когда-то давным-давно peer-group использовались также для оптимизации поведения BGP Потому что BGP-протокол весьма и весьма жручий В части вычислительных мощностей И, соответственно, если вы заносили несколько роутеров в BGP peer-group То у вас по факту вместо того, чтобы обсчитывать поведение каждого конкретного neighbor

Обсчитывалось поведение peer-group А дальше все neighbor просто по этому уже готовому закэшированному образцу обрабатывались И это действительно экономило ресурсы Сегодня это уже не актуально, потому что даже если вы не заносите роутеры в peer-group Cisco всё равно определяет, какие свойства будут общие у некоторых разных роутеров Даже если вы настройки повесите вручную Но вы всё равно одинаковые настройки повесите Однотипно настроенные роутеры Cisco всё равно опознает и назовёт эту штуку Dynamic Peer Group Она всё равно определит, что настройки у разных роутеров одинаковые И посчитает их скопом всё равно Даже если вы не называете это сами peer-group Будет ли конфигурация на neighbor иметь приоритет над тем, что прописано в peer-group? Да Если вы что-то прописали и в шаблоне, и отдельно на neighbor То конфигурация на neighbor имеет приоритет Достаточно очевидно, что это более специфичная настройка по сравнению с шаблонной

Так, давайте попробуем подключиться к нашим роутерам и понастраивать BGP Давайте попробуем подключиться к нашему Видео