Пир-группы для упрощения BGP-конфигурации
О чём этот урок
Пир-группы для упрощения и унификации BGP-конфигурации при большом числе соседей.
Ключевые выводы
- Пир-группы сокращают объём конфигурации и снижают вероятность ошибок при большом количестве соседей.
- Общие параметры (remote-as, update-source, фильтры) задаются один раз для всей группы.
- Каждый сосед в группе автоматически наследует все параметры пир-группы.
- Для конкретного соседа внутри группы можно переопределить любой параметр — он получит приоритет.
- Пир-группы особенно полезны на Route Reflector с большим числом клиентов с идентичными настройками.
Проверьте себя
Какое преимущество дают пир-группы при большом количестве BGP-соседей?
Можно ли переопределить параметр пир-группы для конкретного соседа?
Где пир-группы особенно полезны?
Какие параметры можно задать один раз для всей пир-группы?
Как сосед наследует параметры пир-группы?
Связанные уроки
Смотрите также
Peer-groups и Route Reflectors — оба механизма масштабирования BGP в крупных сетях: peer-groups снижают дублирование конфигурации, RR — дублирование полных mesh-сессий
bgp-cisco-af разбирает Address Family в Cisco IOS BGP — peer-groups часто применяются именно в контексте Address Family для унификации настроек соседей
Транскрипция
Еще одной техникой, которая часто применяется в больших BGP-сетях, являются так называемые пир-группы. Единственное, на текущий момент пир-группы – это больше инструмент для администратора, чтобы ему было меньше работы, чтобы была маленькая вероятность ошибок, скажем так. Представим следующую ситуацию. Есть некий муортизатор, например, Rout Reflector. У него есть много клиентов. Клиент 1, клиент 2, клиент 3. Обычно у этих клиентов очень часто может быть много общих параметров. Какие? Например, общий параметр – то, что они находятся в одной и той же удаленной автономной системе. Одинаково ремонтается. У них мы все сессии, например, строим с loopback.
Как вариант. Это, например, может быть первая группа устройств. У нас может быть здесь подключено несколько IBGP-соседей. Например, E1, E2, которые также находятся в одной АЭС. Например, здесь у нас могут быть одинаковые фильтры, которые применяются в направлении АУ. То есть я к чему? Очень часто вы у себя найдете тот факт, найдете такой факт, что соседи настраиваются более-менее однотипно. При этом нет необходимости настраивать каждого соседа в отдельности. Можно настроить сначала все политики для группы, то есть для некой группы. А далее вам просто необходимо каждого соседа поместить в эту группу. Давайте рассмотрим на примере. Прежде всего нам нужно вернуть, нам нужно будет настроить IBGP уже вот так,
согласно нашей целевой топологии. И после этого мы будем использовать марштизатор R7 в качестве раут-рефлектора. И мы поместим марштизаторы R4, R5 и марштизатор R8 в одну пир-группу. Это нам со стороны АЭС 4578. А внутри АЭС 123 мы возьмем марштизатор R2 в качестве раут-рефлектора и поместим соседей R1 и R3 также в пир-группу. Давайте сделаем. Для небольшого ускорения процесса я буду использовать, наверное, блокнот, чтобы не терять много времени для конфигурации.
Так. Какой у нас получается шаблон? Получается раутер IBGP 4578. Мы говорим Neighbor777. Remote.is. 4578. Neighbor777. UpdateSource. UpdateSource. Бак 0. Мы должны это сделать на марштизаторе R4. Но раутер IBGP 4 для начала. Заливаем. Далее то же самое на марштизаторе R5. То же самое делаем на марштизаторе R8. На марштизаторе R7.
Говорим no router IBGP 7. И создаем IBGP 4578. Далее говорим Neighbor. Создаем соседа. Но вместо указания IP-адреса создадим некую группу. Говорим Neighbor IBGP. Например. То есть это будет такой типовой сосед внутри одной автономной системы. И далее говорим, что, например, этот сосед находится внутри автономной системы 4578. Нам нужно обязательно сначала эту пиргруппу создать. Делается это командой Neighbor IBGP пиргрупп. После этого говорим, что сосед относится к автономной системе 4578.
Далее Neighbor IBGP. Указываем на то, что мы делаем update source. Loopback 0. И говорим Neighbor IBGP. Что это наш? Root reflector client. Теперь создаем каждого соседа. В частности, нам понадобятся сессии R7.R4, R7.R5 и R7.R8. Говорим Neighbor 4.4.4.4. И вместо указания каких-либо специфичных атрибутов, мы говорим, что Neighbor такой-то относится к пиргруппе. Peergroup IBGP. Далее Neighbor 5.5.5.5. Относится также к пиргруппе IBGP.
И Neighbor 8.8.8.8. Относится к пиргруппе IBGP. Какой у нас получается конфиг на может саторе R7? Рангенсершнебиджуп. Итак. Мы создали пиргруппу. Мы создали пиргруппу с именем IBGP. Далее. Для соседа с именем IBGP мы сказали, что он находится в такой-то удаленной системе R7.R4.R5.R7.R8. А сессию мы строим с лупбека. То, что этот сосед является R8.Reflector клиентом. А дальше мы просто поместили мужетизаторы R4, R5 и R8 внутрь данной пиргруппы. Расскажем. Проверяем. Show IP IBGP Summary. Как вы видите, у нас установились отношения соседств. Отношения соседств. Если, скажем, show IPBGP Neighbors.
Скажем, 4.4.4.4. Мне кажется, здесь должно показываться то, что он... Да. Как мы видим, если мы грепнем вывод show IPBGP Neighbor, то мы увидим, что данный сосед является членом пиргруппы с именем IBGP. Давайте заанонсируем на R8 опять сеть 172.16.8.0. Как мы убирали раутер BGP. Сейчас на R7 смотрим. В общем, мы получили префикс. Смотрим этот префикс. 172.16.8.0. Видим то, что префикс передается внутри апдейт группы номер 1. Дальше мы говорим show IPBGP.
IPBGP. Абдейт группа номер 1. И видим, что в эту группу входят 3 маршрутизатора. Это как раз те маршрутизаторы, которые относятся к пиргруппе IBGP. Таким образом, если у вас добавляется, например, еще один маршрутизатор, который будет частью автономной системы 4578, вам достаточно просто добавить этот маршрутизатор внутрь пиргруппы, и сосед с ним будет автоматически установлен. Однако иногда случаются специфичные ситуации. Например, предположим, что для какого-то конкретного соседа, который находится уже внутри пиргруппы, для него нужно применить какие-то другие политики. Что делать? Можно создать новую пиргруппу,
вывести нейбора из первой пиргруппы и завести во вторую. Вариант. Но иногда удобнее просто явно что-то переписать. Например, предположим, что между маршрутизатором R7 и R8 я хочу устанавливать IBGP соседство не с интерфейса Loopback 0, а, скажем, с интерфейса Loopback 1. Собираем интерфейс Loopback 0. Я создам интерфейс Loopback 1, задам ему IP-адрес 77. Также включу на нем SPF. И теперь скажу, router BGP 4.5.7.8, neighbor 8.8.8.8,
update source Loopback 1. То есть я буду строить сессию с маршрутизатором R8 уже со своего интерфейса Loopback 1. То есть нам сделал clear IP-BGP neighbor 7.7.7.7. Разорву соседство с 7.7.7. Угу. Нам маршрутизатор R8 show IP BGP summary. Обратите внимание, что сессия остается в состоянии idle. Neighbor active reset, peer close the session. То есть нам явно говорит о том, что маршрутизатор R7 не ждет сейчас, не ждет TCP сессии от маршрутизатора R8 на адрес 4.7.
А ждет он ее на какой адресе? Правильно. На адрес Loopback 1. Это 7.7.7.7.7.7. Давайте нам маршрутизатор R8 говорим router BGP 4.5.7.8. No Neighbor No Neighbor 7.7.7.7.7.0.7.4.7.8. Remote AS 4578. Сейчас соседство должно установиться. Да, так и есть. И давайте я помещу одну сеть в BGP таблицу на маршрутизаторе R5 еще. создам интерфейс g2.5 и внутри раутера bgp 4578 скажу команду network
убеждаюсь в том, что эта сеть попала в bgp таблицу убеждаюсь в том, что она есть на амортизаторе r4 show ip ralbgp есть и соответственно она также должна присутствовать на амортизаторе rs show ip bgp проверяем 172.16.5 обратите внимание что в качестве нахсхопа для данной сети используется адрес 5555 то есть адрес мортизатора r5 получен от соседа с ip адресом 77.77.77.77.77. здесь вот в выводе когда у нас
стало различие между раутер id и ip адресом с которого строится bgp сессия все стало очень очевидно то есть вот это у нас в выводе еще раз это ip адрес вот это это раутер id а поскольку раутер id у нас создается глобально на мортизатор то на r7 он так и остался 4.7 сколько сложно якобы Продолжение следует...