BGP Part 3. Практика.

2023.03.01. Kurapov Alexey.

BGP Part 3. 

                   Схема сети такая же, как в раньше:

                    Поднимем BGP сессию между R2 и R3:

Успешно.

                     Но, количество получаемых префиксов равно 0:

почему?

      Смотрим на R2:

                    Not advertised to any peer – R2 никому не отдает данные префиксы.

                    В eBGP применяется механизм Loop Prevention основан на аттрибуте AS-PATH, рассмотрим подробнее далее при настройке BGP между разными AS.

В нашем случае R1, R2 и R3 находятся в одной AS, между ними поднимается iBGP. Атрибут AS-PATH изначально пустой на R1, т.к. он эти префиксы и поместил в BGP, при передаче от R1 к R2 не меняется:

 т.о. в iBGP механизм Loop Prevention, основанный на AS-PATH и используемый в eBGP не может быть применен. В iBGP в качестве механизма защиты от петель используется правило split-horizon – если роутер получил UPDATE от iBGP соседа, то другим iBGP соседам он его не передает. R2 не отдает префиксы 11.11.11.11/32 и 12.12.12.12/32 в сторону R3, чтобы R3 не отдал их обрано на R1, в противном случае образуется петля маршрутизации.

 

Как обеспечить полученние R3 префиксов 11.11.11.11/32 и 12.12.12.12/32 от R1? Необходимо построить BGP сессиию между R1 и R3. Если добавим в AS еще роутеры, то и они должны строить BGP с R1 для получения от него данных префиксов. Аналогично для прочих префиксов от других роутеров.

Настроим BGP сессию между R1 и R3 и проверим получение R3 префиксов 11.11.11.11/32 и 12.12.12.12/32 от R1:

 

Префиксы получены R3 и помещены в table route:

 

Т.о. в пределах одной AS, когда работает iBGP требуется полносвязная топология или Full-Mesh – когда каждый роутер открывает BGP сессии со всеми остальными. Альтернативами являются применение Route Reflector-ов (аналог DB/BDR в OSPF), либо BGP Confederation.