Предотвращение петель: AS-PATH, Split Horizon, Full Mesh

Итак, на маршраторе R2 присутствует префикс 172.16.10, который получен от единственного IBGP соседа. Время к нашей типологии. И сейчас давайте с вами на маршраторе R2 построим вторую сессию. То есть первая сессия у нас между R1 и R2. Давайте построим BGP-сессию между R2 и R3. И между R2 и R5. Итак, show IP-интерфейс-бриф. Раутер BGP-123. Для связанности между маршратором R2 и R3 у нас используется интерфейс G2.23.

Мы указываем neighbor 10.2.3.3. Remote AS 1.2.3. На маршраторе R3 создаем BGP-процесс. Router BGP-123. BGP-Router ID 3.3.3.3. И прописываем neighbor 10.2.3.2. 10.2.3.2. Remote AS 1.2.3. Сейчас в скором времени должно установиться отношение соседства. BGP-небор is up. Хорошо. И теперь установим отношение соседства между R2 и R5. neighbor 10.2.5.5.

Remote AS. Remote AS 4.5.7.8. Remote AS 4.5.7.8. И на маршраторе R5. Раутер BGP-4.5.7.8. neighbor 10.2.5.2. Remote AS 1.2.3. Проверяем связанность ping. Не здесь. Здесь. Так, отношения соседств поднялись. Show IP BGP summary. Обратите внимание, что появились два новых соседа. И от каждого мы получаем сейчас по ноль префиксов. На маршраторе R3. На маршраторе R3. Show IP BGP summary.

Ноль префиксов. На маршраторе R5. Show IP BGP summary. Обратите внимание на данную вещь. То есть маршратор R5 получает один префикс. Маршратор R3 не получает ничего. Не получает ничего. Давайте проверим еще раз, чтобы убедиться в том, что это так. Почему же? Почему же? Давайте вернемся на маршратор R2. И посмотрим show IP BGP на префикс 172.16.1.0, который у нас есть в BGP таблице. Посмотрим, что он адвертайзится в сторону апдейт группы номер 4. Посмотрим, какие маршраторы присутствуют внутри данной апдейт группы. Show IP BGP. Апдейт группы номер 4. В частности, здесь присутствует только маршратор R5. То есть здесь отсутствует маршратор R3.

Почему так? Здесь нам нужно с вами поговорить об специальном атрибуте, который присутствует в BGP. Этот атрибут называется ISPath. Если я на маршраторе R5 скажу show IP BGP, то я вижу, что мы получили префикс 172.16.1.0 с нахсхопом маршратора R2. И помните, я вам говорил, у нас есть атрибут pass или атрибут ASPath. Здесь присутствует номер автономной системы маршратора R2. Что такое ASPath и как он работает? Давайте нарисуем вот такую картину. Представим, что у нас есть несколько автономных систем BGP.

Думаю, что они соединены между собой. Номера этих автономных систем 10, 20, 30, 40 и 50. Представим, что мы находимся внутри автономной системы номер 10. У нас здесь есть маршратор R1. Здесь есть маршратор R2. Они соединены между собой прямым линком. Здесь у нас присутствует наш префикс. В частности, префикс 172.16.1.0.24. Здесь у нас присутствует маршратор R3. R4. Здесь R5. R6. R7. R8.

R9. R10. И все они вот так вот между собой соединены. Итак. Предположим, что амурсистатор R1 помещает префикс 172.16.1.0 внутрь своей BGP таблицы. Помещает в BGP. В BGP. В нашем случае это делает маршратор. Это делает маршратор R. Кто у нас делает? Кто у нас помещает префикс? Префикс маршратор R2. R5. IPBGP. Нет, не R. R1. Извините. Маршратор R1. Помещает префикс. Обратите внимание, что атрибут ASPASа он пустой. То есть, если мы посмотрим на вывод на маршраторе R1 и на маршраторе R5, то здесь присутствует номер автономной системы.

А на маршраторе R1 нет. Здесь только присутствует тип. То есть, internal. То есть, когда префикс 172.16.1.0 помещается в BGP табличку, у него создается специальный атрибут ASPAS, который становится пустым. Далее. В таком виде этот префикс передается в сторону маршратора R2. Передается в сторону маршратора R2. Посмотрим. На маршраторе R2. Обратите внимание. То же самое. То есть, ASPAS. ASPAS пустой. ASPAS пустой. То есть, здесь он пустой. Почему так? Это первое правило. То есть, если у нас маршратора связаны по IBGP сессии,

то есть, если два маршратора находятся внутри одной автономной системы, то атрибут ASPAS при передаче апдейта, он не меняется. Не меняется. Далее маршратор R2 передает апдейт в сторону маршратора R3. В сторону маршратора R3. И вот здесь маршратор R2. Он знает, что маршратор R3 находится в другой автономной системе. На маршраторе R2 запущена автономная система номер 10. На маршраторе R3 запущена автономная система номер 20. И между ними установлена так называемая external IBGP сессия. или IBGP. В этом случае маршратор R2 добавляет номер своей автономной системы в атрибут ASPAS.

В частности, мы это видим на маршраторе R5 в нашем примере. В нашем примере. Далее маршратор R3 передает апдейт на маршратор R4. С атрибутом ASPUT. Заметьте, между R3 и R4 поднята IBGP сессия. Поэтому атрибут ASPAS не меняется. Он как был 10, так и остается. Далее маршратор R4. У него есть связанность с маршратором R5. Уже по IBGP. Поэтому атрибут ASPAS опять же модифицируется. В нем оставляется номер. То есть к уже существующему ASPASу маршратор R4 добавляет свой собственный номер. Номер 20. Далее. Маршратор R5, когда передает апдейт на маршратор R6,

в этом случае ASPAS не меняется. 20. 10. Далее. Маршратор R6 при передаче апдейта в сторону маршратора R7, поскольку это у нас IBGP сессия, он должен поменять атрибут ASPAS. К существующему ASPAS, который состоит из последовательности AS систем 20 и 10, добавляет свой собственный номер 30. Далее. Маршратор R7 передает апдейт в сторону маршратора R8 по IBGP. И в этом случае, опять же, ASPAS не меняется. Вот там будет 30, 20, 10. Далее. R8 передает апдейт в сторону маршратора R9. Это IBGP сессия. И ASPAS опять видоизменяется. В существующей последовательности 30, 20, 10.

Добавляется собственный номер 40. Далее. R9 передает апдейт в сторону маршратора R10 по IBGP сессии. В этом случае атрибут ASPAS опять же не меняется. Он будет состоять из автономных систем 40, 30, 20, 10. Далее. Между маршраторами R10 и R1 установлена IBGP сессия. IBGP сессия. В этом случае существующий ASPAS 40, 30, 20, 10. Будет видоизменен. И к нему будет добавлен номер 50. Как мы видим, на маршратор R1 пришел апдейт, который он и породил первоначально.

Так вот. Здесь вступает в действие механизм. Механизм, который называется Loop Prevention. На самом деле, когда маршратор получает IBGP апдейт, он проверяет этот ASPAS атрибут. Что он там пытается найти? Прежде всего, он там ищет номер своей автономной системы. Смотрите, на маршраторе R1 номер IBGP процесса номер 10. Поэтому маршратор R1 смотрит, есть ли номер 10 внутри этого ASPAS. В данном случае он есть. То есть, ведь он присутствует. Поэтому маршратор R1 решает, что этот апдейт уже проходил через его собственную автономную систему. Поэтому такой апдейт на входе, он дропается.

Он дропается. Таким образом, не допускается петлевание IBGP апдейта в сети. Это тот механизм, который использует IBGP для предотвращения петель. Окей. Однако это на самом деле не объясняет того факта, что в нашей типологии маршратор R5 получил апдейт, а маршратор R3 не получил. В чем же дело? Давайте мы сейчас в деталях рассмотрели, что происходит между автономной системой. Давайте мы чуть-чуть более подробно рассмотрим процесс внутри одной автономной системы. Итак, предположим, у нас есть маршратор R1, R2, R3 и предположим R4.

Они соединены с какими-то другими автономными системами. И между вот этими для апдейтов, которые ходят по IBGP сессии, у нас отлично отрабатывает механизм IBGP Loop Prevention. Достигается он за счет того, что при IBGP апдейте граничный маршратор добавляет номер своей автономной системы в ASPAS. Но, как я сказал, при IBGP сессии, ASPAS не меняется. Поэтому, к сожалению, это может привести к некоторым не очень хорошим результатам. Представьте, что вы настроили сессию, например, от R1 к R2, от R2 к R4. И между... вот так вот у нас IBGP сессии поставлены. И скажем, от R1 к R4.

Муртизатор R1 добавляет некий префикс X. Добавляет некий префикс X в IBGP табличку. И отдает такой апдейт в сторону муртизатора R2. В этом случае ASPAS у нас пустой. В этом случае ASPAS пустой. Муртизатор R2 при приеме апдейта проверяет. Вот это автономная система у нас номер 10. Проверяет, нет ли номера 10 внутри ASPAS. Там этого номера нет. Поэтому такой апдейт спокойно инсталлируется. И, условно говоря, он может отправиться в сторону муртизатора R4. При этом, поскольку это, опять же, IBGP сессия, то атрибут ASPAS опять же не меняется. Муртизатор R4 инсталлирует такой апдейт и отправляет его в сторону муртизатора R1. Опять же, с пустой, ASPAS. Муртизатор R1 принимает такой апдейт от R4. И здесь дело в том, что он, например, может выбрать...

По сути, у муртизатора R1 теперь есть выбор. Какой из двух апдейтов лучше? Тот, который был порожден изначально или тот, который был выбран от муртизатора R4? Предположим, что муртизатор R1 выбрал лучшим апдейт от R4. Тогда на R1 меняется на XHOP и отправляется апдейт на R2, R2 на R4, на R4 на R1. И вот такая, по сути, у нас в теории может получиться бесконечная петля, которая как раз вызвана тем, что внутри одной автономной системы мы не можем использовать механизм BGP Loop Prevention. Что же делать? Чтобы избежать такой участи, было введено правило, которое называется IBGP Split Horizon.

Что это такое? Давайте на примере. новая система. R1, R2, R3 и R4. Предположим, что сессии построены вот таким образом. Сессии построены вот таким образом. Предположим, что здесь есть некий муртизатор R5. Да? Муртизатор R5. Итак, муртизатор R1. Муртизатор R1. И давайте вот здесь. Их муртизатор R2. Тоже представлен какой-то муртизатор R6. Муртизатор R1 добавляет префикс X внутрь BGP TAMLIT. Внутрь BGP TAMLIT. И далее этот апдейт от муртизатора R1. Единственное, но, позвольте мне, давайте я уберу вот эту, вот эту.

Чуть-чуть более наглядно. Муртизатор R1 отправляет такой апдейт в сторону муртизатора R2. Муртизатор R2 проверяет, от какого соседа был получен данный апдейт. В частности, в данный момент, этот апдейт был получен от IBGP соседа. Муртизатор R2 говорит, окей, я для этого префикса включаю правило Split Horizon. Оно заключается в следующем. Если апдейт был получен от IBGP соседа, то такой апдейт может быть отдан только по IBGP сессии. То есть, если у нас есть связанность от R2 между маршрутизаторами R2 и R3, это IBGP сессия, это IBGP, поскольку они находятся внутри одной автономной системы, то в этом случае маршрутизатор R2

не передает апдейт в сторону маршрутизатора R3. То есть, это сделано для того, чтобы у нас не было петель внутри одной автономной системы. К сожалению, здесь вы можете увидеть, а как же сделать так все-таки, чтобы маршрутизатор R3, а ведь в таком случае маршрутизатор R3 никогда не узнает о префиксе X. В этом случае уже следствием правила IBGP Split Horizon является требованием на полносвязанную топологию внутри одной автономной системы FullMesh IBGP. То есть, если вы хотите, чтобы все ваши маршрутизаторы в сети знали обо всех префиксах, то вам необходимо между ними сделать FullMesh связанность. вот так вот.

Давайте-ка сделаем это в нашей лабораторной работе. Итак, сейчас мы с вами увидели, что на маршрутизаторе R3 у нас ничего нету в IBGP-таблице. Для этого давайте поднимем связанность между маршрутизаторами R3 и R1. между маршрутизаторами R3 и R1. Show IP Interface Brief. Раутер BGP-таблице. Окей. Раутер BGP-таблице. 1.2.3. Neighbor 10.1.3.1. Remote IS 1.2.3. И на маршрутизаторе R1. Neighbor 10.1.3.3. Remote IS 1.2.3. Окей. Соответственно, в скором времени

у меня должно подняться BGP-соседство. BGP-соседство из app. Show IP BGP Summary. И обратите внимание, мы от соседа R1 получили один префикс. Смотрим. Show IP BGP. Все это и есть префикс 10.172.16.1.0. И в качественных схопах стоит адрес 10.1.3.1. Посмотрим. Show IP BGP. BGP-соседство из app. 172.16.1.0. Вот он. То есть при 172.16.1.0 мы его получили от маршрутизатора с раутера ID 11111. Получили его от соседа с IP адресом 10.1.3.1.0. И в качественных схопах используется адрес 10.1.3.1. Show IP Rout BGP. Итак, у нас получается некая причинно-следственная связь.

Смотрите, внутри IBGP, по IBGP-сессии мы не изменяем атрибуты ISPAS. Это приводит к тому, что IBGP не может использовать механизм loop prevention. Это ведет за собой требования на использование IBGP-предвеншена к появлению нового правила, которое называется IBGP-спит-хорайзен, который заключается в том, что если апдейт получен от IBGP-соседа, то данный апдейт может распространяться только в сторону внешних IBGP-соседей, то есть только по IBGP-сессии. И наличие этого правила спит-хорайзена ведет за собой требование, что внутри одной автономной системы у нас должен быть, наш амортизатор, даже связан по full mesh, то есть по полно связанной топологии.

К сожалению, это ведет, как вы знаете, за собой может вести некие проблемы, которые связаны с количеством IBGP-сессий, которые вам приходится сконфигурировать. Об этом мы поговорим на следующем ураке.