Route Reflector: масштабирование iBGP без Full Mesh

Итак, как мы с вами выяснили на прошлом уроке, основной проблемой внутри одной автономной системы BGP является требование на то, чтобы все маршрутизаторы были связаны между собой по full mesh. Почему эта проблема? На картинке у нас есть всего лишь 4 маршрутизатора. Давайте посчитаем, сколько сессий нам необходимо настроить. Одна сессия между R1 и R2, одна сессия между R2 и R3, третья сессия между R3 и R4, четвертая сессия между R1 и R4, пятая сессия между R1 и R3 и шестая сессия между R2 и R4. Всего 6 сессий для 4 маршрутизаторов. При этом 6 сессий, то есть вы должны понимать, что вы настраиваете сессии с двух сторон, и всего их получается 12.

На самом деле есть формула, которая звучит следующим образом. Некое количество сессий S, это будет N на N-1 в квадрате, мы делим пополам. То есть если у нас 4 маршрутизатора, то у нас получается, что мы 4 умножаем на 3, делим пополам, то у нас получается 6 сессий. То есть 6 сессий и 12 настройок. Теперь представьте, что будет, если количество маршрутизаторов увеличится, ну скажем, до, не знаю, хотя бы до 10. То есть это получится уже порядка 10 на 9, то есть получится уже 45 сессий и так далее. То есть у вас количество настроек возрастает пропорционально квадрату количества маршрутизаторов, которые у вас есть.

Что, наверное, не очень хорошо и не очень удобно. Поэтому был придуман специальный функционал, который называется отражатели маршрутов. Отражатели маршрутов. Что же это такое? Что же это такое? Пусть у нас есть несколько маршрутизаторов. Предположим, R1. Эй, случайно. Я случайно закрыл. Я не случайно закрыл, а программа вылетела с ошибкой, я извиняюсь. Я извиняюсь. Так, предположим, что у нас есть несколько маршрутизаторов.

R1. R2. R3 и R4. R3 и R4. Предположим, у нас есть некий дополнительный маршрутизатор R5. Мы можем сделать следующее. Мы можем поднять IBGP-сессии между маршрутизатором R1 и R5, между R2 и R5, между R3 и R5 и между R4 и R5. Мы можем настроить маршрутизатор R5 специальным образом. Мы его настраиваем как отражатель маршрутов. Или в английской терминологии мы его настраиваем как раут-рефлектор. Все эти маршрутизаторы R1, R2, R3 и R4 становятся так называемыми раут-рефлектор-клиентами.

Раут-рефлектор-клиент. На самом деле нет специальной роли клиентов. То есть это обычный. То есть для маршрутизатора R1 не знает о том, что R5 является раут-рефлектором. То есть для маршрутизатора R1 у него будет обычная IBGP-сессия. Все модификации делаются исключительно на раут-рефлекторе. Каким же образом работает раут-рефлектор? В частности получается следующее. Предположим, что маршрутизатор R1 помещает некий префикс X в BGP-таблицу. Далее он ее передает только в сторону раут-рефлектора. По IBGP-сессии. Мурсетер R5 видит, что он получил данный префикс от клиента.

И поэтому он модифицирует свой IBGP-сплит-хорайзен. Правила IBGP-сплит-хорайзена в данном случае модифицируются следующим образом. Если мы получили IBGP-апдейт от своего раут-рефлектора клиента, то, во-первых, мы этот апдейт отражаем на всех остальных клиентов. То есть маршрутизатор R5 отдает этот апдейт в сторону R2, в сторону R3 и в сторону R4. Таким образом, все маршрутизаторы R2, R3 и R4 узнают о префиксе X. Далее. Предположим, что у маршрутизатора R5 также есть дополнительный пиринг с маршрутизатором R6,

который использует IBGP. В этом случае префикс от раут-рефлектора клиента точно так же будет отдан по IBGP-сессии. По IBGP-сессии. И предположим, что у нас есть еще один маршрутизатор R7, у которого настроена сессия между маршрутизатором R5, но данный маршрутизатор R7 не является раут-рефлектор клиента. То есть это обычный IBGP-пиринг с точки зрения R5 и с точки зрения R7. Так вот, в этом случае R5 также отдаст префикс в сторону маршрутизатора R7. То есть таким образом у нас получается, что если мы получаем апдейт от клиента, то мы его высылаем IBGP-пиром, IBGP-пиром и всем своим IBGP-раут-рефлектор клиентам.

Давайте проверим, как это работает на практике. У нас есть топология. И маршрутизатор R3, R1, R2. Я буду использовать маршрутизатор R1. Давайте я буду использовать не R1, я лучше буду использовать маршрутизатор R2 в качестве рут-рефлектора. В качестве рут-рефлектора. Итак, я могу погасить сессию между R1 и R3, то есть она мне здесь больше не нужна. Говорим router BGP и отключаем сессию между R1 и R3.

То же самое сделаем на R3. router BGP. router BGP. No Neighbor. Окей, сделал. Получается, что только на стороне марштизатора R2 show IP BGP summary. Со стороны марштизатора R2 у меня есть два двух соседа. Со стороны марштизатора R3 show IP BGP summary. Со стороны марштизатора R1 show IP BGP summary. Это все самое. Есть один сосед. Окей, соответственно, марштизатор R1 передает внутрь BGP подсеть 172.16.1.0.

У нас вот здесь есть сеть, которую марштизатор адвертает во внешний мир. Марштизатор R1 передает эту подсеть на марштизатор R2. Теперь наша задача сделать так, чтобы R2 отзеркаливал этот маршрут в сторону марштизатора R3. Давайте попробуем это сделать. Со стороны клиентов, то есть со стороны марштизаторов R1 и R3, никакая дополнительная настройка не требуется. Все, что нам нужно, это войти в конфигурацию BGP на R2 и сделать следующее. Сказать, что neighbor марштизатор R1 является для нас клиентом. В частности, за это будет отвечать команда route-reflector-client. И для марштизатора R3, и марштизатор R3 для нас также будет являться клиентом.

Также являться клиентом. С точки зрения R1 и R3 я ничего не менял. Единственное, что здесь BGP будет немножко перезапущен. Скажу так логически. Потому что для R3 они стали клиентами, и он должен выслать… Рассказывается, что R2 инициирует изменение BGP соседства. Почему? Потому что, если мы скажем, show ip-bgp-neighbors для адреса 10, например, 233, то вы здесь увидите, что это route-reflector-client. Рoute-reflector-client. Теперь что получается. Мурцизатор R1 передает подсеть внутрь BGP-таблицы.

Этот префикс достигает route-reflector-show ip-bgp. Теперь давайте посмотрим show ip-bgp-172.16.1.0. Мы видим, что этот префикс отдается в сторону групп с номерами 4 и 5. show ip-bgp-update. update-group, я думаю, это будет номер 5. И здесь мы видим, что у нас здесь есть два соседа. R1 и R3 – это наши внутренние соседи. Соответственно, на амортизаторе R3 проверяем BGP-таблицу show ip-bgp. Как видите, нам известен network-172.16.1.0. Давайте посмотрим. show ip-bgp-172.16.1.0. С точки зрения R3 ничего не поменялось.

За исключением одного. Обратите внимание, у нас появляется некий дополнительный атрибут. Этот атрибут называется оригинатор и кластер-лист. Давайте посмотрим, что это такое. И давайте посмотрим, присутствует ли данный атрибут на амортизаторе R1, то есть на том амортизаторе, который этот префикс породил. Обратите внимание, здесь ничего нет. Здесь ничего нет. Соответственно, очевидно, что вот эти вот параметры добавляются root-рефлектором. Но добавляются они только тогда, когда апдейт передается в сторону. То есть если апдейт был получен от root-рефлектор клиента и передается в сторону root-рефлектор клиента, то мы добавляем определенные атрибуты.

В частности, оригинатор и кластер-лист. Что это такое и для чего нужно? Оригинатор указывает нам на то, каким маршрутизатором этот префикс был порожден изначально. В нашем случае префикс был порожден маршрутизатором R1. Что такое кластер-лист? Кластер-лист — это параметр самого root-рефлектора. Параметр самого root-рефлектора. То есть как только... Наша типология сейчас следующая. R1, R3 и R2, которые являются root-рефлектором. R1 передает префикс 172.16.1.0 в сторону маршрутизатора R2. В сторону маршрутизатора R2. R2 видит, что этот префикс получен от root-рефлектора клиента.

Значит, этот апдейт должен быть отражен в сторону другого root-рефлектора клиента. При этом, при этом, на исходящем апдейте мы дополнительно добавляем параметр, который называется cluster-list. По умолчанию, по умолчанию, этот cluster-list равен нашему BGP router-id. BGP router-id. При этом он может быть изменен. На маршрутизаторе R2 мы можем сделать, например, router-id.gp123. И, например, сказать BGP cluster-list. И, скажем, назовем cluster-list 100, 100, 100, 100. С нами маршрутизатор R3. Видим, что cluster-list поменялся, и теперь это адрес 100, 100, 100, 100. То есть, по сути, это router-id самого root-рефлектора.

Для чего он нужен? Смотрите, если наши клиенты имеют теперь IBGP connectivity только с root-рефлектором, то получается, что root-рефлектор становится одним из самых критичных узлов в вашей сети. То есть, если R2 выйдет из строя, то все ваши амортизаторы в сети, которых могут быть десятки, сотни, они не смогут обменяться маршрутами друг с другом. Поэтому очень часто router-рефлекторов ставят несколько. Их ставят несколько. Предположим, у нас здесь появляется дополнительный амортизатор R4, который также используется как router-refлектор. Как router-refлектор. С-теном. У амортизатора R2 есть свой кластер ID.

И у R4 есть свой кластер ID. Предположим, что амортизатор R1 соединен только с амортизатором R2, а амортизатор R3 соединен только с амортизатором R4. Это возможно, например, в том случае, если амортизатор R1 стоит в Москве, R3 стоит где-нибудь в Хабаровске. И при этом вы и router-refлектора делите также по территориальному признаку. Например, один router-refлектор в Москве, другой в Хабаровске. Так вот, предположим, что кластер ID вы назначили одинаковый. В этом случае амортизатор R3 передает апдейт в сторону R4.

R4 видит, что он получил апдейт от своего router-refлектора клиента, поэтому он должен отдать этот префикс своим router-refлектор клиентам раз и просто IBGP соседям. В частности, у вас обязательно будет IBGP-сессия между вашими router-refлекторами. Амортизатор R4 отражает маршрут в сторону амортизатора R2. Зашивая внутрь BGP апдейта свой кластер ID, который на нем сконфигурирован. Амортизатор R2 получает такой апдейт и видит, что он был порожден им самим же, поскольку кластер ID совпадает. В результате такой апдейт дропается. В результате такой апдейт дропается. Поэтому, если вы используете один и тот же кластер ID на ваших двух router-refлекторах,

это говорит о том, что два этих маршрутизатора представляют собой некий условный кластер. Они не синхронизируют никакую информацию друг с другом. Но они с точки зрения router-refлектора выступают как один маршрутизатор. Поэтому все ваши клиенты должны быть подключены к обоим маршрутизаторам. Я не говорю здесь про физические соединения. Между ними обязательно должна быть установлена логическая IBGP-сессия. В этом случае маршрутизатор R4 отдаст апдейт не только в сторону R2, но он отдаст его и в сторону маршрутизатора R1. У вас может появиться логичный вопрос. А почему мы здесь дропаем? Почему апдейт такой не обрабатывается? Дело в том, что он интерпретируется IBGP-процессом как петля. Давайте предположим, что R2 не дропает апдейт,

а отдает его в сторону клиента. Тут проблема в том, что маршрутизатор R2 не знает, как настроен R1. Например, на R1 вы можете настроить так, что R2 и R4 будут являться клиентами, router-reflector клиентами для R1. Поскольку конфигурация делается независимо на каждом устройстве. Что в таком случае произойдет? R2 отдаст апдейт в сторону R4. То есть, по сути, R4 получает апдейт обратно. Потом опять его отдает на R2. И таким образом у вас могут апдейты запетлеваться. И у вас получится такая петля на уровне control plane. Соответственно, чтобы ее не было, вам необходимо, чтобы апдейты, которые передаются внутри одного router-reflector кластера,

чтобы они дропались вдруг. Это ведет за собой требование к тому, что все клиенты должны быть подключены ко всем физическим амортизаторам кластера. Я имею в виду логическую IBGP-сессию. Соответственно, что делать, если у вас сеть действительно очень большая? Вы можете использовать несколько router-reflector. Вы можете использовать, например, router-reflector 1. Можете использовать router-reflector 2. Вот ваши амортизаторы R3 и R4. То есть, условно говоря, у вас слева это Москва, справа это Хабаровск. Тогда у router-reflector 1 будет кластер ID. Кластер ID равный 1.

У router-reflector 2 будет кластер ID равный 2. И в этом случае ваши клиенты подключаются сессиями только к ближайшим router-reflector. А передача маршрутов пойдет каким образом? R4 передает на R2. R2, когда передает апдейт в сторону амортизатора R1, он туда добавляет свой кластер ID. И router-reflector 1 передает его в сторону амортизатора R3. Поэтому вопрос, скажем, что же лучше использовать в сети, например, чтобы ваши два router-reflector образовывали единый кластер, либо чтобы они были независимыми, это исключительно остается на усмотрение вашего дизайна,

на усмотрение вашего архитектора. То есть, может быть, на ваше усмотрение. Но в целом, я бы, наверное, рекомендовал следующим образом. Если у вас сеть не сильно распространена, скажем, территориально, например, это какое-то одно здание, то в этом случае обычно используется один кластер. Если же ваша сеть географически распределена, например, сеть сервис-провайдер, того же МТС, Мегафона, Ростелекома, то в этом случае обычно создают несколько территориальных рут-рефлекторов. Однако, может получиться так, что количество рут-рефлекторов, даже когда вы делаете некую географическую привязку,

их рут-рефлекторов тоже может быть очень много. Например, представьте Ростелеком. У него там сеть от Мурманска до Владивостока. Поэтому, чтобы избежать фулл-меша уже между рут-рефлекторами, иногда вводят дополнительный уровень рут-рефлекторов. То есть вы можете поставить, скажем, третий уровень рут-рефлекторов, который будет использоваться только для того, чтобы отражать маршруты уже между вашими существующими рут-рефлекторами. Предположим, что… То есть когда может полез? Например, левый рут-рефлектор – это какой-нибудь там… Не знаю, скажем, он где-нибудь в Европе расположен. А рут-рефлектор 2 расположен, скажем, во Владивостоке. А вот такой центральный рут-рефлектор может быть расположен, например, в Москве.

Это, опять же, просто один из вариантов. Какие маршрутизаторы в сети делать рут-рефлекторами? Обычно это диктуется исключительно физической топологией вашей сети. Давайте с вами на лабораторной работе посмотрим… Посмотрим следующее. Я могу временно настроить сеть таким образом. Если у меня маршрутизатор R2 является рут-рефлектором на текущий момент, давайте я и маршрутизатор R5 также отдам под рут-рефлектор. То есть у меня будет вот это – рут-рефлектор 1, вот это у меня будет рут-рефлектор 2. Вот это будет рут-рефлектор 2. Я на них сконфигурирую один и тот же кластер ID, например, 100, 100, 100, 100.

Маршрутизатор R3 будет иметь сеть только с маршрутизатором R2, а маршрутизатор R1 будет иметь сеть только с маршрутизатором R5. И, соответственно, маршрутизатор R2 будет перейти с маршрутизатором R5 только уже по IBGP в этой конкретной лаборатории. Давайте сделаем такую вещь… Итак, на маршрутизатор R5… Show run section… BGP… Router BGP… Router BGP… Пусть это будет 1, 2, 3… Neighbor… Neighbor…

1, 2, 3… А единственное, я хочу обратить ваше внимание… Поскольку я поменял номер автономной системы у себя, я пока поменял только на R5, я вижу, что ко мне прилетают сообщения от маршрутизатора R2, которые мне говорят о том… то ко мне прилетают сообщения от маршрутизатора R2, которые мне говорят о том, что на маршрутизаторе R2 в сторону маршрутизатора R5 настроена неправильная автономная система. Раутер BGP 1, 2, 3. И, соответственно, я настрою вот этого нейбора. Remote AS 1, 2, 3.

Далее мне нужно погасить соседство между R1 и R2. Между R1 и R2. То есть вот здесь вот я говорю Neighbor Shutdown. Neighbor Shutdown. И вместо мне потребуется дополнительный интерфейс, чтобы не трогать маршрутизаторы R4, R7, R5. Я подниму дополнительный интерфейс между R1 и R5. Он будет у меня временный. Временный. То есть я не планирую использовать в следующих лабораторных работах. Но, тем не менее, давайте мы его пока поднимем. Итак, я создам интерфейс G2.15. Это будет 15-ая VLAN с IP-адресом 10.1.5.1.

И помещу его в SPF. Допинк 10.1.5.1. У меня появилась связность. С-цена. Теперь я могу поднять BGP с Ss. Neighbor 10.1.5.5. Remote IS 1.2.3. На муштизаторе R5. Раутер BGP 1.2.3. Говорю, что BGP Cluster ID.

Да, у меня тот же 100, 100, 100, 100. 100, 100, 100, 100. Далее включу Debug IP BGP Update. То есть буду смотреть, что происходит. И скажу, что муштизатор R1 для меня является раут-рефлектор клиентом. Neighbor 10.1.5.1. Remote IS 1.2.3. И ты для меня являешься раут-рефлектор клиентом. Что же происходит? Что же происходит? Муштизатор R1.

Show IP BGP Summary. У него есть сессия только, как вы видите, с муштизатором R5. Сессия с муштизатором R2 неактивна. Находится в состоянии idle. Сессия с муштизатором R2 нам говорит о том, что у нас не может быть установлено TCP соединение с соседом. Префикс отдается на муштизатор R2. На муштизатор R2. Show IP BGP. Сейчас, кстати, на муштизаторе R2 почему-то нет. Ой, извиняюсь. Мы отдаем его в сторону... Так, я запутался. Сейчас, секунду. Префикс мы генерируем на муштизаторе R1 и отдаем его в сторону муштизатора R5. Все правильно. То есть на муштизаторе R5 смотрим. Show IP BGP. Есть префикс. Посмотрим, кому мы его отдаем. Мы его отдаем в BGP группе 1. Show IP BGP.

Update группа 1. Мы его отдаем в сторону муштизатора R2. А на муштизаторе R2 у нас префикс отсутствует в BGP таблице. Давайте посмотрим, почему. Я здесь включу debug IP BGP updates. Debug BGP updates. И скажу clear IP BGP in. То есть я попрошу всех сейчас своих соседей заново мне переслать свою BGP таблицу. Обратите внимание, что муштизатор R2 на самом деле получает update для сети 172.16.1.0, но он denied. Do you reflect from the same cluster? То есть муштизатор R2 получает update с кластер-листом 100-100-100-100.

Этот кластер-лист добавил муштизатор R5. Он прилетает на муштизатор R2. И поскольку на двух root-рефлекторах настроен один и тот же кластер ID, такой апдейт просто дропается. Такой апдейт просто дропается. И к чему мы приводим? А это приводит нас к тому, что муштизатор R3, show IP BGP, он этот префикс больше не получает. Префикс больше не получает. Как мы можем исправить ситуацию? Как мы можем исправить эту ситуацию? Нам потребуется, нам потребуется, либо чтобы муштизаторы R3 были подцеплены к обоим root-рефлекторам, то есть чтобы у нас были вот такие соединения, IBGP-сессии. Это в том случае, если R2 и R5 представляют собой единый кластер. Либо же мы можем R2 и R5 разбить на два независимых кластера.

И тогда R3 может иметь сессию, например, только с R2, а R1 может иметь связанность только с R5. Давайте настроим разные кластеры ID на двух муштизаторах. На R2 и на R5. В частности, на самом деле, будет достаточно на одном из муштизаторов поменять кластер ID. Раутер BGP. 1, 2, 3. BGP. Кластер ID, например, 55, 55, 55, 55. Окей, соответственно, мы высылаем сразу апдейт, поскольку у нас изменился наш кластер ID. Здесь на муштизаторе R2 мы видим, что к нам прилетает апдейт на сеть 172.16.1.0.

На сеть 172.16.1.0. Кластер лист уже 55, 55, 50, 55. То есть это уже не наш кластер лист. И что мы делаем? Мы его инсталируем. Route Installing. Инсталируем его в свою IP Table. И таким образом, этот префикс должен сейчас появиться на муштизаторе R3. BGP. 172.16.1.0. И обратите внимание, что муштизатор R3 уже видит два. То есть он внутри своего кластера, внутри атрибута кластер лист, он видит оба кластера. То есть он видит кластер, который состоит сейчас из муштизатора R5 и кластер, который состоит из муштизатора R2. Из муштизатора R2. То есть муштизатор R2,

когда получил апдейт, и когда он высылает его своим клиентам, он этот кластер лист не перезаписывает, а туда добавляет самого себя. То есть опять же, это нужно для того, чтобы если потом апдейт вдруг вернется, скажем, вернется обратно к муштизатору 55, 55, 55, 55, чтобы он его смог откинуть, как произошла петля на Ctrl-P. Продолжение следует...