Конфедерации BGP: разбиение AS на суб-AS

Вторым вариантом масштабирования BGP-сетей являются так называемые конфедерации. Конфедерация представляет механизм, при котором вы разбиваете одну большую автономную систему на несколько маленьких. Скажем, на 10 штук. При этом все эти конфедерации должны быть как-то связаны между собой. А внутри каждой конфедерации у вас работает обычный IBGP-соседство. К сожалению, у этого метода есть один огромнейший недостаток, который привел к тому, что конфедерации почти никогда не внедряются на сетях, которые уже существуют. На так называемых brownfield-сетях. Почему, спросите вы.

Это очень простой. Мы это увидим, когда мы будем заниматься конфигурированием. Дело в том, что вам нужно полностью будет выключить протокол муштизации BGP, сказать no router BGP, и переконфигурировать все устройства в вашей сети, что может быть довольно-таки большим неудобством и может привести к очень большому простой в сети. При этом никто не запрещает вам использовать внутри конфедерации, скажем, те же router-рефлектора. Таким образом можно добиться максимальной масштабированности. Давайте посмотрим, как все это выглядит на картинках. Итак, предположим, что есть автономная система. Есть некая автономная система. Большая автономная система. У нее есть сколько-то муштизаторов.

1, R2, R3, R4, R5, R6, R7. Здесь пусть будет R8, здесь пусть будет R9. И есть пилинги с внешними автономными системами. Автономными системами, предположим, что черная – это автономная система номер 100. Имеет пилинг с автономной системой номер 200. И здесь есть пилинг с автономной системой номер 30. Что же такое конфедерация? Давайте разберемся. Мы можем, если мы понимаем, что количество IBGP-сессий даже с учетом рут-рефлекторов становится очень большим, можно сделать следующее. Берем, например, группу муштизаторов.

И выделяем их в отдельную автономную систему. Вот так называемую конфедерацию. И, например, даем ей некий номер. Скажем, муштизатор 123. Пусть будет автономная система номер 123. Муштизаторы, например, 4 и 9 выделяем в конфедерацию номер 49. Далее. 5 и 6 выделяем в 56. И, скажем, 7 и 8 выделяем в конфедерацию номер 78. Внутри конфедерации мы устанавливаем классические IBGP-сессии. Здесь будет свой IBGP. Внутри 49 будет свой IBGP. Внутри 56, собственно, свой.

И внутри 78 автономная система свой. То есть, например, муштизатор R3 может выступать, скажем, в качестве рут-рефлектора. Для своей конфедерации. Далее. Нам необходимо связать автономные системы, связать конфедерации между собой. Например, у нас есть физическое соединение между муштизатором R8 и R1. Между, скажем, между R4 и R9. Скажем, между R5 и R4. И между R7 и R6. Так вот. Вот это соединение, оно, конечно, по факту будет IBGP. Поскольку фактически перед автономной системой номер 123 и 78. Но это так называемый IBGP конфедерейшн. В чем суть?

Поскольку мы знаем, что сотая автономная система поглощает все конфедерации, то фактически все муштизаторы находятся под единым административным управлением. По факту у нас работают единые политики муштизации. Давайте рассмотрим, что будет происходить с атрибутом ISPath при передаче префикса между конфедерациями. Предположим, что за муштизатором R1 есть некая сеть X, которую мы помещаем в IBGP. Неважно как. Мы можем поместить ее с помощью команды Network, можем поместить ее с помощью команды Redistribute. Муштизатор R1 передает этот префикс в сторону муштизатора R3 с пустым ISPath. Муштизатор R3 передает этот маршрут в сторону R2 также с пустым ISPath.

Далее. Что произойдет между R2 и R4? В классическом варианте, когда у нас обычная IBGP-сессия, муштизатор R2 должен был бы добавить внутрь ISPath номер своей автономной системы. Здесь примерно то же самое, но с одним исключением. С одним исключением. Каким же? Когда мы настраиваем конфедерации, у нас внутри атрибута ISPath появляется дополнительный тип ISPath, который называется ISConfederationSequence или ISConfederationSet. По сути, вот здесь вот, именно сюда будут добавляться наши автономные системы, которые сконфигурированы как автономные системы конфедерации.

То есть, в частности, когда муштизатор R2 будет передавать апдейт на муштизатор R4, то ISPath, по сути, останется почти что пустым. А выглядит он будет вот так. То есть, у нас появляются открытые скобочки. И внутрь этих скобок муштизатор R2 помещает номер своей автономной системы. Номер 123. Номер 123. То есть, вот это и есть ISConfederationSet или ISConfederationSequence. Нужно, то есть, этот ISConfederationSequence используется для предотвращения, то есть, используется как механизм loop prevention для маршрутов,

которые распространяются внутри, скажем так, родительской автономной системы. Окей. Далее. Муштизатор R4 передает соответствующий апдейт на муштизатор R9, то есть, он его не меняет, и передает его в сторону муштизатора R5. Когда апдейт передается в сторону муштизатора R5, то ISPath меняется вот таким вот образом. То есть, у нас появляется номер здесь 49, и он припендится к номеру 123. Далее. Когда муштизатор R6 передает на муштизатор R7, ISPath у нас выглядит таким образом. То есть, он по факту пустой, но и содержит только ISConfederationSequence. 56, 49 и 123. Естественно, когда муштизатор R8 будет передавать маршрут обратно на R1,

то ISPath будет выглядеть таким образом. Будет состоять только из набора конфедераций. 78, 56, 49, 123. Соответственно, муштизатор R1, когда принимает апдейт, он понимает, что он принимает его не от реального IBGP-пира, а от своего IBGP-конфедерейшн-пира. Он начинает проверять не сам ISPath на повторение, а именно ISConfederationSequence. Находит внутри ISConfederationSequence номер своей автономной системы, и таким образом маршрут здесь дропается. Маршрут здесь дропается. Вернемся к маршрутизатору R9, который получил апдейт от маршрутизатора R4.

Маршрутизатор R9 передает апдейт в сторону автономной системы 300. Дело в том, что автономная система 300 ничего не знает и не должна знать о вашей внутренней структуре сети, о ваших конфедерациях. Вообще обычно номера конфедерации берутся из приватного диапазона. Поэтому что маршрутизатор R9 делает? Он первоначально получил апдейт, который содержит ISConfederationSequence. Но этот апдейт должен быть передан реальному IBGP-пиру. Поэтому маршрутизатор R9 вырезает ISConfederationSequence из исходящего апдейта и заменяет ISConfederationSequence на номер своей реальной автономной системы. Аналогично поступает маршрутизатор R8,

когда передает апдейт в сторону автономной системы 200. Он вырезает Sequence 5649123 и передает только номер своей реальной автономки. Давайте посмотрим, как это выглядит на практике. Под конфедерацию нам придется сделать отдельную топологию. Мы будем работать внутри автономной системы 4578, но при этом мы разобьем ее на 4 конфедерации, которые будут автономной системы 4578. 4578.

Итак, сначала нам нужно будет удалить show run section BGP. Мы удаляем старый BGP процесс, no router BGP 123, no router BGP 4578, здесь 7-й show run section BGP, здесь нету BGP, и на 8-м маршрутизаторе тоже ничего нет. Следующая наша задача, следующая наша задача, это, извиняюсь, сейчас я потерял свою топологию, это создать BGP процесс на каждом из маршрутизаторов, на 4-м, 5-м, 7-м и 8-м. При этом на маршрутизаторах запускается BGP процесс с номером конфедерации.

Не с номером родительской автономной системы, а с номером конфедерации. Итак, на маршрутизаторе R4 создается раутер BGP4, на маршрутизаторе R5 создается раутер BGP5, на 7-м раутер BGP7, и на 8-м создается раутер BGP8. Следующим шагом мы должны указать номер реальной автономной системы, то есть тот, который будет подставляться для реальных IBGP-пиров. Для этого используется команда из блока BGP Confederation. BGP Confederation Identifier. Здесь мы указываем номер нашей реальной автономной системы, 4-5-7-8. Далее. BGP Confederation Peers. То есть здесь мы указываем номера автономных систем

других конфедераций в нашей глобальной автономной. BGP Confederation Peers. Будет 4-7-8. 4-7-8. Аналогичную процедуру проделываем на амортизации. На амортизации R4. Это BGP Confederation Identifier. 4-5-7-8. BGP Confederation Peers. 5-7-8. На амортизации R7. BGP Confederation Identifier. 4-5-7-8. BGP Confederation Peers. 4-5-8. И на амортизации R8. BGP Confederation Identifier. 4-5-7-8. BGP Confederation Peers.

4-5-7. Сделали. Следующим шагом установим отношения соседства между амортизаторами R4 с R7 и R5 с R7. Сначала я хочу проверить свою таблицу амортизации. Nlical. AfterShowite. В все notice, E outros spend. Так. Dillical. 1424. 4647. 14. Здесь у меня есть линк 24, я его хочу сейчас убрать. Он мне не нужен. из 2.24 который остался у нас с прошлой лабораторной работы и так мы знаем был бэк нашего мартизатора r7 делаем раутер биджи пин 4 neighbor 7777

рима ута с номер 7 например набор 7777 ставим слабак то же самое делаем на пятом neighbor 7777 рима ута с 7 7 7 7 обдельцу субок но и то же самое получится у нас на восьмом 7 7 7 7 7 7 и на мартизаторе r7 говорим neighbor 4 4 4 4 remote as 4 верим что сейс устроен слабака далее neighbor

5 5 5 5 5 5 5 5 5 5 на практически listen vs navigation по Так, проверяем настройку. Show IP BGP Summary. Обратите внимание, что все нейборы пока что находятся в состоянии idle. Idle нам говорит о том, что у нас не установлены TCP сессии. Команда show TCP brief покажет, что ничего не сделано. Посмотрим. Show IP BGP Neighbors. Show IP BGP Neighbors. 4.4.4.4.

BGP State is idle. BGP State is idle. Include TTL. Нету здесь такого. Да, у нас есть проблема, потому что, видите, RIP doesn't have a route to 4.4.4.4. GOдей. Show IP RAW 4.4.4.4.4. Проверим базовую connectivity. Проверим базовую connectivity.

Проверим базовую connectivity. О том, что это конфедерейшн. Находится в конфедерации. Я неправильно прочитал. Написано does have a round. Обратите внимание на следующую запись. External BGP neighbor not directly connected. External BGP neighbor configured for connected.

Check. Single hope. О чем это говорит? Все дело в том, что в качестве транспорта у нас используется TCP. По умолчанию для IBGP соседства используется TTL равный 255. Для IBGP соседства используется TTL равный 1. По умолчанию. Поэтому, что у нас на самом деле происходит? Это касается не только конфедерации. Это касается любой IBGP связности. Представим, что у нас есть маршрута R1 и R2. Которые соединены прямым линком. И мы строим BGP сессию между loopback. Здесь пытаемся прокинуть TCP-туннель. Мортизатор R1 генерит TCP-син с TTL равным 1.

И с destination IP-адрес, который равен loopback мортизатора R2. И высылает такой пакет в сторону своего соседа. Мортизатор R1 принимает пакет. Далее видит, что пакет предназначается не вот этому интерфейсу. Пакет попадает на обработку в таблице мортизации. Находится выходной интерфейс. И при этом уменьшается TTL. То есть TTL уменьшается с единички до нуля. А как вы знаете, любые пакеты с TTL равным 0 просто откидываются. Поэтому нам нужно увеличить TTL. Если мы хотим строить IBGP сессию с loopback интерфейсов. Делается это следующим образом. Мы заходим в раутер IBGP. И говорим neighbor 4.4.4. И здесь есть замечательная команда, которая называется IBGP multihop.

То есть allow IBGP neighbors not directly connected networks. Мы говорим IBGP multihop. И дальше выставляем необходимое значение TTL. Например, давайте выставим 10. Neighbor 5.5.5.5. IBGP multihop 10. Neighbor 8.8.8. IBGP multihop 10. То же самое нам необходимо будет сделать на всех остальных устройствах. IBGP multihop 10. Neighbor 7.7.7.7. IBGP multihop 10. И на четвертом мустизаторе. Раутер IBGP 4. Neighbor 7.7.7.7.

IBGP multihop 10. Возвращаемся к мустизатору 7. Мы видим, что у нас уже поднялись два соседа. Поднялся четвертый сосед. Show IPBGP summary. Пока от них не получаем никаких префиксов. Но это ожидаемо, потому что они нам ничего не анонсируют. Давайте поднимем... Давайте даже не так. Для того, чтобы поднимем, а создадим на мустизаторе R8 дополнительный интерфейс. Вот здесь. И этот интерфейс, эту подсеть мы заанонсируем в IBGP. Вот. На мустизаторе R8. На мустизаторе R8 поставим интерфейс G2.8. Incubsylation. Dot1k8. И здесь будет IP-адрес. 172.16.8.8. 255.255.255.0.

И в раутере BGP проанонсируем эту сеть. 172.16.8.0. Mask. 255.255.0. Получается show IP BGP. Префикс появился. Давайте посмотрим детальную информацию о нем. Как мы видим, этот префикс анонсируется в сторону update группы 1. В частности, update группы 1 – это, очевидно, наш мустизатор R7. Умстизатор R7. Проверим show IP BGP summary и видим, что мы от 8-го мустизатора получили один префикс. Давайте на него посмотрим. Show IP BGP. Как вы видите, да, префикс заинсталлирован. При этом IS-пас у нас составляет… Внутри IS-пути прописана конфедерация номер 8. 172.16.8.0.

Здесь мы видим, что это маршрут, который получен от Confederation XTAR. Далее проверим, что у нас происходит на мустизаторе R4. Show IP BGP. Как вы видите, мустизатор R4, поскольку он получил этот префикс транзитом через R7, то для него префикс выглядит как конфедерация 7.8. И аналогичная ситуация должна наблюдаться на мустизаторе R5. 7.8. Хорошо. Хорошо. Между мустизатором R5 у нас должно быть связан с мустизатором R2. Давайте проверим настройки на мустизаторе R2. Show Rung Section BGP. На мустизаторе R2 у нас есть настроение отношения состязанства с мустизатором R5, который на текущий момент находится в состоянии idle.

Давайте сделаем раутер BGP5. Говорим команду neighbor 10.2.5.2. Remote AS 1.2.3. В виде мустизатора R5 реально сконфигурирован раутер BGP5. Однако мустизатор R2 видит его, как будто бы он находится внутри автономной системы 4578. Почему? Потому что на мустизаторе R5 есть следующая строчка. Во-первых, задан BGP Confederation Identifier. То есть это тот номер автономной системы, которым мустизатор R5 будет представляться для реальных и BGP-сессий.

А как мустизатор R5 понимает, реальная ли это BGP-сессия, либо же это сессия типа Confederation External? Для этого используется команда BGP Confederation Peers, в которой мы перечисляем все номера автономных систем, которые являются конфедерацией. Давайте посмотрим, что же происходит с BGP-таблицей на мустизаторе R2. ShowApplyGP. Обратите внимание, что префикс 172.16.8.0 известен через NexHop, который принадлежит мустизатору R5, и при этом IS-пассы составляют только одну автономную систему. То есть если на мустизаторе R5 префикс 172.16.8.0 имеет пустой IS-пасс с заполненным, скажем так, под атрибутом, IS-confederation sequence, то при передаче апдейта от R5 к R2

IS-confederation sequence убирается, и вместо него ставится номер реальной автономной системы. Давайте для чистоты эксперимента поднимем еще связанность между мустизаторами R8 и R9. На мустизаторе R9. Раутер BGP9. Берем Neighbor 10.8.10.8. Remote IS-4.5.7.8. И на мустизаторе R8. Раутер BGP. То есть еще раз обратите внимание, что на мустизаторе R8 номер BGP процесса 8. А для внешних соседей он будет виден как 4578. Здесь мы говорим просто Neighbor 10.8.10.9. Remote IS-9.

Neighbor is up. Show IPBGP на мустизаторе R9. Покажет нам то, что мы выучили префикс 172.16.8.0, в котором точно так же отсутствует параметр IS-confederation sequence, но вместо него присутствует обычный IS-пасс. Show IPBGP на 172.16.8.0. Также вы здесь можете убедиться, что нет абсолютно никаких упоминаний об IS-confederation. Надеюсь, вам понравился данный урок. Увидимся на следующем.