Различия IBGP и EBGP

1) Главная тонкость, которая появляется при переходе внутрь Автономной Системы и откуда растут ноги почти всех отличий — петли. В EBGP мы с ними справлялись с помощью AS-Path. Если в списке уже был номер собственной AS, то такой маршрут отбрасывался. Но, как вы помните, при передаче маршрута внутри Автономной Системы AS-Path не меняется. Вместо этого в IBGP прибегают к хитрости: используется полносвязная топология — все соседи имеют сессии со всеми — Full Mesh. При этом маршрут, полученный от IBGP-соседа не анонсируется другим IBGP-соседям. Это позволяет на всех маршрутизаторах иметь все маршруты и при этом не допустить петель.

Поясним на примерах.

Как это могло бы быть в такой топологии, например, если не использовать технологию избежания петель: R1 получил анонс от EBGP-соседа, передал его R2, тот передал R3, R3 передал R4. Вроде, все молодцы, все знают, где находится сеть Интернет. Но R4 передаёт этот анонс обратно R1. R1 получил маршрут от R4, и он по выгодности точно такой-же, как оригинальный от ISP — AS-Path-то не менялся. Поэтому в качестве приоритетного может выбраться даже новый маршрут от R4, что, естественно, неразумно: мало того, что маршруты будут изучены неверно, так и трафик в итоге может заloopиться и не попадёт к точке назначения.

В случае же полносвязной топологии и правила Split Horizon, такая ситуация исключается. R1, получив анонс от ISP1, передаёт его сразу всем своим соседям: R2, R3, R4. А те в свою очередь эти анонсы сохраняют, но передают только EBGP-партнёрам, но не IBGP, именно потому, что получены от IBGP-партнёра. То есть все BGP-маршрутизаторы имеют актуальную информацию и исключены петли.

Причём, не имеет значение, подключены соседи напрямую или через промежуточные маршрутизаторы. Так, например, на вышеприведённой схеме R1 не имеет связи с R3 напрямую — они общаются через R2, однако это не мешает им установить TCP-сессию и поверх неё BGP.

Понятие Split Horizon тут применяется в более широком смысле. Если в RIP это означало «не отсылать анонсы обратно в тот интерфейс, откуда они пришли», в IBGP это означает «не отсылать анонсы от IBGP-партнёров другим IBGP-партнёрам.»

2) Вторая тонкость — адрес Next Hop. В случае External BGP маршрутизатор при отправке анонса своему EBGP-соседу сначала меняет адрес Next-Hop на свой, а потом уже отсылает. Вполне логичное действие.

Вот как анонс сети 103.0.0.0/22 выглядит при передаче от R5 к R1:

Если же маршрутизатор передаёт анонс IBGP-соседу, то адрес Next-Hop не меняется. Хм. Непонятно. Почему? Это расходится с привычным пониманием DV-протокола маршрутизации.

Вот тот же анонс при передаче от R1 r R2:

Дело в том, что здесь понятие Next-Hop отличается от того, которое используется в IGP. В IBGP он сообщает о точке выхода из локальной AS.

И тут возникает ещё один момент — важно, чтобы у получателя такого анонса был маршрут до Next-Hop — это первое, что проверяется при выборе лучшего маршрута. Если его не будет, то маршрут будет помещён в таблицу BGP, но его не будет в таблице маршрутизации.

Такой процесс называется рекурсивной маршрутизацией.

То есть, чтобы R2 мог отправлять пакеты ISP1 он должен знать, как добраться до адреса 101.0.0.1, который в данной схеме и является Next-Hop'ом для сети 103.0.0.0/22.

В принципе, практически всё оборудование даёт возможность менять адрес Next-Hop на свой при передаче маршрута IBGP-соседу. На циске это делается командой "neighbor XYZ Next-Hop-self". Позже вы увидите, как это применяется на деле.

3) Третий момент: если в EBGP обычно подразумевается прямое подключение двух соседей друг к другу, то в Internal BGP соседи могут быть подключены через несколько промежуточных устройств.

На самом деле в EBGP также можно настраивать соседей, которые находятся за несколько хопов друг от друга и это на самом деле практикуется, например, в случае настройки Inter-AS Option C. Называется это дело MultiHop BGP и включается командой "neighbor XYZ ebgp-multihop" в режиме конфигурации BGP. Но для IBGP это работает по умолчанию.

Это позволяет устанавливать IBGP-партнёрство между Loopback-адресами. Делается это для того, чтобы не привязываться к физическим интерфейсам — в случае падения основного линка, BGP-сессия не прервётся, потому что лупбэк будет доступен через резервный. Это самая распространённая практика.

При этом EBGP однако обычно устанавливается на линковых адресах, потому что как правило имеется только одно подключение и в случае его падения, всё равно Loopback будет не доступен. Да и настраивать ещё какую-то дополнительную маршрутизацию с провайдером не очень-то хочется.

Пример конфигурации такого соседства:

Вам нужно стараться избегать ситуаций, когда между IBGP-соседями будут не-BGP маршрутизаторы.

Вообще-то есть механизм, позволяющий если не исправить, то по крайней мере предупредить такую ситуацию, — IGP Synchronization. Он не позволит добавить маршрут в таблицу, если точно такой же маршрут не известен через IGP. Это в какой-то мере гарантирует, что на промежуточных устройствах, независимо от того, активирован на них BGP или нет, будут нужные маршруты. Но я не знаю тех десперадо, которые решились включить IGP Synchronization. Во-первых, каким образом такие маршруты попадут в IGP? Только редистрибуцией. Теперь представьте себе, как Full View медленно наполняет LSDB OSPF, проникая в отдалённые уголки памяти и заставляя процессор до изнеможения выискивать кратчайшие маршруты. Хотите ли вы этого? А, во-вторых, вытекающее из «во-первых», по умолчанию, IGP-synchronization выключен практически на всех современных маршрутизаторах.