Доброго дня!Нужно продублировать BGP роутер, работающий на базе FreeBSD+Quagga(zebra). Вторая система уже настроена. Осталось настроить конфиги BGP. Пожалуйста, помогите с определением правильных терминов в целях нахождения ссылок на материалы для чтения.
========================
Интересуют схемы:
========================1. Оба активных одновременно.
2. Один активный, другой на подхвате, на случай если упадет первый.
========================
Соответственно вопросы:
========================1. Можно ли для одной AS иметь одновременно два активных BGP роутера на один аплинк к провайдеру (без деления подсетей)?
2. Можно ли организовать Fail-Over с одним аплинком?
Вы подключаетесь к одному BGP-роутеру провайдера? Если да, то любая схема обеспечит резервирование собственных серверов FreeBSD. Если вы подключаетесь к двум роутерам провайдера в одной подсети (даже по одному аплинку), то будет обеспечен резерв провайдерского роутера. В обоих случаях BGP-роутеры должны быть подключены через коммутаторы.
> Вы подключаетесь к одному BGP-роутеру провайдера? Если да, то любая схема обеспечит
> резервирование собственных серверов FreeBSD. Если вы подключаетесь к двум роутерам провайдера
> в одной подсети (даже по одному аплинку), то будет обеспечен резерв
> провайдерского роутера. В обоих случаях BGP-роутеры должны быть подключены через коммутаторы.С нашей стороны в настройках указан один провайдерский neighbor. А что там у них на самом деле — не понятно.
Железо уже подключено и настроено через коммутатор. Через второй роутер уже проверили выход в свет, трафик проходит.
Первый BGP-роутер маршрутизирует трафик в оба направления, но его нужно будет остановить на тех.обслуживание. С целью минимизировать простой, подняли второй роутер. Но чтобы каждый раз настройки не перекидывать ручками с одного на другой, хотим максимально по возможности это дело автоматизировать. Соответственно и встал вопрос. Как настроить два BGP роутера на работу одновременно или по схеме один-упал-второй-поднялся (Fail-Over)?
Правильно ли я понимаю, что fail-over обеспечивается на стороне аплинка, т.е. это вышестоящий провайдер на своем роутере настраивает схему работы один-упал-другой-поднялся? А мы со своей стороны обеспечиваем только смену DEFAULT GATEWAY c нашего GW1 на GW2?
+---------------------+
+ UPLINK (BGP сессия) +
+---------------------+
|
|
+----------------+
+ SWITCH +
+----------------+
| |
+-----+ +-----+
+ GW1 + + GW2 +
+-----+ +-----+
| |
+----------------+
+ SWITCH +
+----------------+
| | | | | | | |
... ... ... ... ...
>[оверквотинг удален]
> +-----+ +-----+
> |
> |
> +----------------+
> + SWITCH
> +
> +----------------+
> | | | | | | | |
> ... ... ... ... ...
>
Не совсем понимаю, что подразумевается под понятием fail over. Что мешает поднять iBGP между вашими серверами и наладить обмен маршрутами между ними? Как отдаются маршруты в ядро сети с граничных серверов (отдаете только дефолт)?
> Не совсем понимаю, что подразумевается под понятием fail over. Что мешает поднять
> iBGP между вашими серверами и наладить обмен маршрутами между ними?iBGP между серверами с квагой?
> Как
> отдаются маршруты в ядро сети с граничных серверов (отдаете только дефолт)?Да, только дефолт.
> iBGP между серверами с квагой?Необходимо больше информации о том, как вы создаете маршруты на свои сети внутри AS (агрегация, статика в null). Как ваши сервера получают информацию о внутренних подсетях AS. Это может быть важно при развертывании второго сервера и подключения к провайдеру. Опять же, есть ли такие сервисы на граничных серверах как NAT.
> Необходимо больше информации о том, как вы создаете маршруты на свои сети
> внутри AS (агрегация, статика в null). Как ваши сервера получают информацию
> о внутренних подсетях AS. Это может быть важно при развертывании второго
> сервера и подключения к провайдеру. Опять же, есть ли такие сервисы
> на граничных серверах как NAT.Внутри AS все маршруты статические. На сервере с квагой работают BGP+Zebra. NAT не используется.
>> Необходимо больше информации о том, как вы создаете маршруты на свои сети
>> внутри AS (агрегация, статика в null). Как ваши сервера получают информацию
>> о внутренних подсетях AS. Это может быть важно при развертывании второго
>> сервера и подключения к провайдеру. Опять же, есть ли такие сервисы
>> на граничных серверах как NAT.
> Внутри AS все маршруты статические. На сервере с квагой работают BGP+Zebra. NAT
> не используется.Если вы хотите обеспечить резервирование своего сервера на время работ, но просто поднимите еще одну сессию с провайдером, отдайте 0/0 внутрь AS и чините первый сервер.
> Если вы хотите обеспечить резервирование своего сервера на время работ, но просто
> поднимите еще одну сессию с провайдером, отдайте 0/0 внутрь AS и
> чините первый сервер.Премного благодарен.
А чтобы IP шлюза для AS с одного на другой перекидывать что можно использовать? Скрипт писать? Или можно как-то более цивилизованно? Хочу знать на тот случай, если таки решим дальше оба сервера держать на постоянных условиях.
>> Если вы хотите обеспечить резервирование своего сервера на время работ, но просто
>> поднимите еще одну сессию с провайдером, отдайте 0/0 внутрь AS и
>> чините первый сервер.
> Премного благодарен.
> А чтобы IP шлюза для AS с одного на другой перекидывать что
> можно использовать? Скрипт писать? Или можно как-то более цивилизованно? Хочу знать
> на тот случай, если таки решим дальше оба сервера держать на
> постоянных условиях.Предлагаю вам познакомиться с протоколами маршрутизации и BGP в частности. В такой простой топологии все ваши задачи выполняются штатными функциями.
> Предлагаю вам познакомиться с протоколами маршрутизации и BGP в частности. В такой
> простой топологии все ваши задачи выполняются штатными функциями.Отлично, это я и хочу сделать. Только подкиньте, пожалуйста, пару терминов или ключевых слов, чтобы конкретизировать поиск. Боюсь всю документацию по BGP не осилю.
>>> Если вы хотите обеспечить резервирование своего сервера на время работ, но просто
>>> поднимите еще одну сессию с провайдером, отдайте 0/0 внутрь AS и
>>> чините первый сервер.
>> Премного благодарен.
>> А чтобы IP шлюза для AS с одного на другой перекидывать что
>> можно использовать? Скрипт писать? Или можно как-то более цивилизованно? Хочу знать
>> на тот случай, если таки решим дальше оба сервера держать на
>> постоянных условиях.
> Предлагаю вам познакомиться с протоколами маршрутизации и BGP в частности. В такой
> простой топологии все ваши задачи выполняются штатными функциями.в некоторых дизайнах vrrp может быть более, чем достаточно.
Если с английским особых проблем нет - поищите цисковский курс для ccnp1, там какраз про протоколы маршрутизации...
> в некоторых дизайнах vrrp может быть более, чем достаточно.
Ага, кажется, это то, что нужно)))
Благодарю за наводку, мы уже в процессе изучения и настройки freevrrpd-1.0 под FreeBSD.
> freevrrpd-1.0 под
> FreeBSD.Чего-то не удается ее "завести"... Буду пробовать еще ucarp.
>[оверквотинг удален]
> +-----+ +-----+
> |
> |
> +----------------+
> + SWITCH
> +
> +----------------+
> | | | | | | | |
> ... ... ... ... ...
>Если вы анонсируете свои сети в сторону провайдера по двум аплинкам, то роутер вашего провайдера решит, через какой из ваших маршрутизаторов направить трафик в вашу сеть. И в случае, если один из ваших серверов упадет, то роутер провайдера будет это "учитывать" при выборе следующей точки перехода в направлении вашей сети.
>
> Если вы анонсируете свои сети в сторону провайдера по двум аплинкам, то
> роутер вашего провайдера решит, через какой из ваших маршрутизаторов направить трафик
> в вашу сеть. И в случае, если один из ваших серверов
> упадет, то роутер провайдера будет это "учитывать" при выборе следующей точки
> перехода в направлении вашей сети.
>Благодарю, это как раз то, что я и хотел знать.
>>
>> Если вы анонсируете свои сети в сторону провайдера по двум аплинкам, то
>> роутер вашего провайдера решит, через какой из ваших маршрутизаторов направить трафик
>> в вашу сеть. И в случае, если один из ваших серверов
>> упадет, то роутер провайдера будет это "учитывать" при выборе следующей точки
>> перехода в направлении вашей сети.
>>В общем с помощью инженеров апстрима вопрос решили по трафику в нашу AS. Теперь есть основной линк и бэкапный. Осталось решить вопрос по выходу трафика из AS, т.е. с обновлением/перемещением DEFAULT GATEWAY для хостов внутри AS.