Заезженный вопрос про iBGP

[LostSoul]

Имеются BGP маршрутизаторы R1 , R2 , R3  , связаны между собой выделенными каналами L1,  L2 , L3  каждый с каждым.

Все три маршрутизатора относятся к одной AS.

 

Маршрутизатор R1 имеет включение во внешние сети и взаимодействует по EBGP с другими AS.

Маршрутизаторы R2 и R3 имеют взаимодействие только с R1 и друг с другом, по iBGP.

 

К маршрутизатору R2 и R3 подключены клиенты , которым нужно обеспечить резервирование связи через канал  L3 в случае обрыва основных каналов L1 и L2.

 

Поднимать на каналах что-то типа OSPF не хочется, хочется обойтись iBGP.

 

Проблема классическая, заключается в том, что R2 не хочет анонсировать для R1 маршруты, разученные по iBGP от R3.  И аналогично, R3 не хочет выдавать R1 маршруты, разученные по iBGP от R2.

 

Играть всеми комбинациями instance client-to-client-reflection , peer route-reflect , peer nexthop-choice я попробовал, и к успеху не пришел.

А именно - если включить route-reflect то маршруты начинают анонсироватся, но с nexthop из недоступной напрямую подсети ( отделенной маршрутизатором ) , и в итоге всё равно не работают.

nexthop-choice = force-self в ситации никак не помогает.

 

Можете ткнуть в ссылку как такое правильно настроить?

 

 

 

[rz3dwy]

М.б. исползовать Sub-AS для связи между роутерами для обеспечения квази-фуллмеш при отказе любого из L1,L2?

 

Edited May 6, 2018 by rz3dwy

[LostSoul]

6 часов назад, rz3dwy сказал:

М.б. исползовать Sub-AS

Ну это как-то совсем кривенько.

так как на самом деле структура сети сложнее, упростил для примера.

в качестве присоединяемых на узлах r2 и r3 могут быть железки типа  cisco me3400 , которым надо по BGP отдать default + доступные местные подсети.  И скорее всего каталист в отличии от микротика не сумеет несколько bgp instance.

А в качестве R1 в некоторых случаях может быть например 1U сервер c frr или quaga или что-то ещё экзотическое по случаю.

 

 

[rz3dwy]

Так это особенность iBGP - неанонсирование маршрутов другим соседям. Либо RR либо confederation нужно использовать. 

[LostSoul]

1 час назад, rz3dwy сказал:

Либо RR либо confederation нужно использовать. 

Так я включаю RR , но он у меня не взлетает годным способом.

Mikrotik не меняет nexthop на IP своего интерфейса, доступного пиру, а оставляет таким каким он был получен.

В итоге peer получает nexthop в недоступном ему влане

 

[LostSoul]

Да и что делать с sub-as, если роутеров в цепочке станет не  3шт , а например 4шт ?

 

или какая-то более сложная топология

 

[LostSoul]

Отвечаю сам себе,  всё оказалось элементарно.

 

1) включаем /routing bgp instance set client-to-client-reflection=yes

2) у каждого peerN ставим /routing bgp peer set peerN set route-reflect=yes

3) для исправления кривого nexthop добавляем фильтр  /routing filter add chain=peerN-out set-out-nexthop=<ip-адрес этого роутера в влане стыка с peerN

4) вешаем этот фильтр на пир  /routing bgp peer set rJ2 out-filter=peerN-out

 

получаем то желали - все IGP маршруты,  полученные от соседа в цепочке роутеров, улетают другому соседу а nexthop выставляется на роутер между ними.

Недоумеваю , почему такое просто решение не мог никто подсказать.

 

[LostSoul]

Дополнительно.

Второй непростой задачей оказался выбор оптимального маршрута.

Так как на каждый mikrotik в кольце хоть и приходит 2 варианта пути , но ему абсолютно неведомо какой из них оптимальный.

 

Для решения этой задачи указанный выше export filter   для соседа в кольце был переделан следующим образом

 

1) на каждом роутере при экспорте префикса увеличиваем ему значение аттрибута med на единицу.  Целевой роутер выбирает маршрут с минимальным med ( то есть с минимальным числом хопов )

 

Пример для mikrotik R2   ,  с IP-адресом в сторону R1 - 172.16.1.2  , в сторону R3 - 172.16.3.1

 

Цитата

 

add bgp-med=2 chain=out-r1 set-bgp-med=3 set-out-nexthop=172.16.1.2
add bgp-med=1 chain=out-r1 set-bgp-med=2 set-out-nexthop=172.16.1.2
add bgp-med=0 chain=out-r1 set-bgp-med=1 set-out-nexthop=172.16.1.2

 

add bgp-med=2 chain=out-r3 set-bgp-med=3 set-out-nexthop=172.16.3.1
add bgp-med=1 chain=out-r3 set-bgp-med=2 set-out-nexthop=172.16.3.1
add bgp-med=0 chain=out-r3 set-bgp-med=1 set-out-nexthop=172.16.3.1

 

 

Таким образом , при просмотре таблицы маршрутов на R2 мы будем видеть,

что для подсети 185.246.50.128/25 ( анонсируемой с R3 ) будет  nexthop 172.16.1.1 с med = 2 и 172.16.3.2  с med=1.

До тех пор пока кратчайшее соединение доступно, трафик будет бегать в обе стороны по кратчайшему пути.

 

В моем случае R1 это не микротик , а linux box с демоном маршрутизации bird.

Для него годные фильтры оказались следующие
 

Цитата

filter out_R2 {
if source ~ [ RTS_BGP ] then bgp_med = bgp_med + 1;
else bgp_med=1;
accept;
}

filter out_R3 {
if source ~ [ RTS_BGP ] then bgp_med = bgp_med + 1;
else bgp_med=1;
accept;
}

 

 

Надеюсь, кому-то мой опыт окажется полезным.

 

[morf]

Еще как.

[Dmytro]

Я правильно понимаю, в схеме "треугольника" все роутеры имеют идентичную конфигурацию. Но на лабораторном стенде не могу получить требуемый результат, next-hop не анносируется :(. Можете выложить экспорт ветки routing, чтобы посмотреть ваши настройки bgp и filters.

Edited December 10, 2019 by Dmytro

[LostSoul]

И снова, для тех кто придет страдать , как сделать set-out-nexthop  в ROS7.

 

делается так

/routing rules add chain=peer1-out disabled=no rule="set gw 172.16.3.1;accept;"

без accept в конце не работает.

[HarDik]

 

В 09.05.2018 в 17:55, LostSoul сказал:

Отвечаю сам себе,  всё оказалось элементарно.

 

1) включаем /routing bgp instance set client-to-client-reflection=yes

2) у каждого peerN ставим /routing bgp peer set peerN set route-reflect=yes

3) для исправления кривого nexthop добавляем фильтр  /routing filter add chain=peerN-out set-out-nexthop=<ip-адрес этого роутера в влане стыка с peerN

4) вешаем этот фильтр на пир  /routing bgp peer set rJ2 out-filter=peerN-out

 

получаем то желали - все IGP маршруты,  полученные от соседа в цепочке роутеров, улетают другому соседу а nexthop выставляется на роутер между ними.

Недоумеваю , почему такое просто решение не мог никто подсказать.

 

А если схема другая? Имеется одна AS и два маршрутизатора и два канала между ними ibgp и как сделать так что бы они оба работали с разными аплинками? Пока вот не могу с этим разобратся, побороть... ((

[sol]

46 минут назад, HarDik сказал:

Имеется одна AS и два маршрутизатора и два канала между ними ibgp и как сделать так что бы они оба работали с разными аплинками? Пока вот не могу с этим разобратся, побороть... ((

И в чём проблема? Просто поднимаете BGP к аплинкам, и между бордерами тако-ж. И всё.

 

[HarDik]

34 минуты назад, sol сказал:

И в чём проблема? Просто поднимаете BGP к аплинкам, и между бордерами тако-ж. И всё.

 

То есть ibgp между бордарами излишне ?

Просто я понимаю так что между нужен ibgp , а они уже имеют ebgp с аплинками? Для передачи маршрутов...

 

Иди я ошиблась ?

 

Просто уже достаточно много времени разбираюсь с этим , и уже каша в голове

Не понимаю как адекватно заставить анонсировать одну AS с двух разных бордеров и  разных аплинков , причем что бы и там и там маршруты работали правильно.

Порт попытки все построить , из вне  маршрут ходит кругами ... 

 

Edited May 6, 2024 by HarDik

[DeLL]

Вам нужно понять что такое iBGP И eBGP, для чего они нужны. Если станет понятно - тогда и свою задачу решите

[HarDik]

1 час назад, DeLL сказал:

Вам нужно понять что такое iBGP И eBGP, для чего они нужны. Если станет понятно - тогда и свою задачу решите

Все понятно, но задача так и не решена, так как есть проблема с подливанием маршрутов, при этом   next-hop force self не помогает, так же понял что надо применять Фильтр ignore  AS-Path length,  но видимо понимание не пришло и тоже не спасает ситуацию. 

Пока не понял куда принять что бы не было петли

Забыл на писать на одном роутере 6.49.12 , на другом 7.11

Edited May 6, 2024 by HarDik

[DeLL]

о какой петле речь? конфиги в студию вместе с фильтрами

 

[sol]

19 часов назад, HarDik сказал:

То есть ibgp между бордарами излишне ?

Тут такое дело. Это работает как с носками. Как только один назначен правым, второй автоматически становится левым.

 

Если поднять BGP между АС с одинаковыми номерами, то он автоматический становится i. А если между разными АС, то опять сам, автоматически e.

 

[Saab95]

В 06.05.2024 в 21:18, HarDik сказал:

Забыл на писать на одном роутере 6.49.12 , на другом 7.11

Нужна одинаковая версия прошивки, т.к. в 7-й очень хитро настраиваются фильтра BGP и ваши сети могут просто там "теряться".

[HarDik]

В 18.05.2024 в 01:45, Saab95 сказал:

Нужна одинаковая версия прошивки, т.к. в 7-й очень хитро настраиваются фильтра BGP и ваши сети могут просто там "теряться".

Понимаю, могут быть проблемы именно с настройками , но вроде все сделано по канонам , так сказать , но все равно проблему победить не смог.

Есть опыт настройки bgp на 6 и 7 версии, но в таком варианте не разу .

Фильтра все на вроде настроены более или менее правильно.

Но... Возможно , нет понимания в чем ошибка.

И по прежнему добиться работы не получилось .

Уже руки опустились... Не знаю что не так.

 

P.s. У вас я знаю опыт большой, возможно вы чем то подскажите и направите на путь истинный...

 

В 07.05.2024 в 15:03, sol сказал:

Тут такое дело. Это работает как с носками. Как только один назначен правым, второй автоматически становится левым.

 

Если поднять BGP между АС с одинаковыми номерами, то он автоматический становится i. А если между разными АС, то опять сам, автоматически e.

 

Логично...)

Но в любом случаи , победить нормально проблему не смог , маршрут ходит кругами или вообще не анонсируется .

((

Фик знает почему .

[Saab95]

2 часа назад, HarDik сказал:

У вас я знаю опыт большой, возможно вы чем то подскажите и направите на путь истинный.

Делаете идентичные настройки на обоих роутерах BGP для связи с вышестоящими провайдерами и анонсируете сети. Включаете только один роутер - все работает, включаете только второй роутер - все работает.

 

Соединяете эти 2 роутера между собой с помощью OSPF. В настройках указываете анонсирование дефолтного маршрута. К роутерам подключаете другие роутеры распределения сети так же через OSPF и все будет отлично работать.

 

Исходящий трафик пойдет через те каналы, которые ближе к абонентам. То есть если запрос пришел на роутер 1, то он и отправит его в интернет. Ответ вот может придти на любой роутер, но через внутреннюю сеть OSPF он попадет к абоненту. Естественно, НАТ не должен работать на роутерах BGP, а где-то уже дальше внутри сети, что бы не терялись ответы, если на другой роутер поступят.

 

Всякие там iBGP вообще не нужны для работы с простыми задачами. Их предназначение - работа на очень больших сетях, где штук 50 BGP роутеров с внешними аплинками, или когда сами абонентам предоставляете линки по BGP уже дальше на своей сети.

[sol]

В 22.05.2024 в 22:42, Saab95 сказал:

Соединяете эти 2 роутера между собой с помощью OSPF. В настройках указываете анонсирование дефолтного маршрута. К роутерам подключаете другие роутеры распределения сети так же через OSPF и все будет отлично работать.

 

Исходящий трафик пойдет через те каналы, которые ближе к абонентам. То есть если запрос пришел на роутер 1, то он и отправит его в интернет. Ответ вот может придти на любой роутер, но через внутреннюю сеть OSPF он попадет к абоненту. Естественно, НАТ не должен работать на роутерах BGP, а где-то уже дальше внутри сети, что бы не терялись ответы, если на другой роутер поступят.

 

Всякие там iBGP вообще не нужны для работы с простыми задачами. Их предназначение - работа на очень больших сетях, где штук 50 BGP роутеров с внешними аплинками, или когда сами абонентам предоставляете линки по BGP уже дальше на своей сети.

 

На дальнем от абонента роутере пир с IX, а пакеты для IX уйдут через ближний кружным путём. Замечательная схема.

 

[HarDik]

В 23.05.2024 в 00:42, Saab95 сказал:

Естественно, НАТ не должен работать на роутерах BGP, а где-то уже дальше внутри сети, что бы не терялись ответы, если на другой роутер поступят.

В этом и проблема что НАТ находится там же где и bgp.

Я как понимаю что, надо или выводить НАТ на отдельную железку или анонсировать другую подсесть и использовать раздельные подсети для НАТа.

В голове были планы анонсировать AS через два роутера, через разные аплинки , между собой понять ospf/bgp, нат запустить через разные адреса , но с одной подсети...

Но видимо желания  и действительность расходятся ...

Edited May 27, 2024 by HarDik

[Saab95]

Если на одном БГП сервере сделать нат через 10 адресов 1-2-3-4-5-6-7-8-9-10, а на втором бгп сделать нат через 10 адресов 101-102-103-104-105-106-107-108-109-110, при этом соединить оба БГП прямым линком - то НАТ будет работать без проблем, но вот как входящий трафик пойдет управлять не особо получится.

 

Если же есть 2 подсети /24, то можно анонсировать их обе с каждого роутера, но весами маршрутов БГП сделать так, что бы на одном роутере до чужой подсети был длиннее маршрут, и на втором противоположную подсеть. Тогда трафик этих подсетей пойдет по своим БГП и проблем не возникнет с перетоком трафика.

 

Но можно поступить проще - отказаться от этого устаревшего протокола BGP и подсетей, а просто брать в аренду подсети у других операторов.

 

Тогда в точке 1 можно подключить оператора А1 и оператора Б1, у каждого взять по 256 или более белых адресов и делать на них НАТ.

В точке 2 взять у оператора А2 и оператора Б2 так же по 256 белых адресов и делать НАТ уже на них. При этом сам НАТ можно делать где угодно на сети, и трафик пойдет именно по нужным адресам.

 

Тем самым имеем много плюсов - нет своего БГП и проблем с маршрутами, распределением нагрузки, всякими документами и ТСПУ от регуляторов. Имеем избыточность по IP адресам. Если один оператор сломается - мгновенно можно переключить трафик с отключенных белых адресов на другие и все.

 

По деньгам что за аренду адресов платить, что за аренду БГП платить, что за аренду "своих" IP платить - то же на то и выходит.

[DeLL]

Так и запишем - BGP устаревший протокол