URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID6
Нить номер: 23307
[ Назад ]

Исходное сообщение
"BGP-резервирование"

Отправлено Fred , 22-Ноя-11 18:10 
Добрый день. Прошу совета по маршрутизации
есть своя AS, PI /23, из которого одна /24 используется, вторая пока нет.
стоит по шкафу в двух разных датацентрах.
1 датацентр анонсирует наш as+pi, оттуда работают сервисы. В 2 датацентре хотим сделать резервную площадку, чтобы при аварии в 1 ДЦ и пропадании анонсов все продолжало работать с 2 ДЦ. Синхронизация машин уже есть, интересует возможно ли анонсировать эту же AS+PI с другого ДЦ c меньшим приоритетом? Возможно ли в качестве теста анонсировать с 2 ДЦ только нашу неиспользованую /24 ? Есть ли опыт реализации таких схем у кого-то?

Содержание

Сообщения в этом обсуждении
"BGP-резервирование"
Отправлено Merridius , 22-Ноя-11 21:34 
>[оверквотинг удален]
> есть своя AS, PI /23, из которого одна /24 используется, вторая пока
> нет.
> стоит по шкафу в двух разных датацентрах.
> 1 датацентр анонсирует наш as+pi, оттуда работают сервисы. В 2 датацентре хотим
> сделать резервную площадку, чтобы при аварии в 1 ДЦ и пропадании
> анонсов все продолжало работать с 2 ДЦ. Синхронизация машин уже есть,
> интересует возможно ли анонсировать эту же AS+PI с другого ДЦ c
> меньшим приоритетом? Возможно ли в качестве теста анонсировать с 2 ДЦ
> только нашу неиспользованую /24 ? Есть ли опыт реализации таких схем
> у кого-то?

Если датацентры в пределах одного провайдера, то проще соединить их через mpls vpn.


"BGP-резервирование"
Отправлено Fred , 23-Ноя-11 11:24 
> Если датацентры в пределах одного провайдера, то проще соединить их через mpls
> vpn.

Провайдеры разные, сетки друг друга видят через UA-IX.


"BGP-резервирование"
Отправлено Merridius , 23-Ноя-11 11:30 
>> Если датацентры в пределах одного провайдера, то проще соединить их через mpls
>> vpn.
> Провайдеры разные, сетки друг друга видят через UA-IX.

Ну тогда может через mpls over gre?
Вообщем смысл такой, если не соединить ваши бордеры по igp, то анонсить придется разные сети в датацентрах. Теряется резервирование.  


"BGP-резервирование"
Отправлено Fred , 23-Ноя-11 11:42 
> Ну тогда может через mpls over gre?
> Вообщем смысл такой, если не соединить ваши бордеры по igp, то анонсить
> придется разные сети в датацентрах. Теряется резервирование.

Можно поподробнее про mpls over gre - что мне это даст?


"BGP-резервирование"
Отправлено Merridius , 23-Ноя-11 11:51 
>> Ну тогда может через mpls over gre?
>> Вообщем смысл такой, если не соединить ваши бордеры по igp, то анонсить
>> придется разные сети в датацентрах. Теряется резервирование.
> Можно поподробнее про mpls over gre - что мне это даст?

http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide...


"BGP-резервирование"
Отправлено fantom , 23-Ноя-11 13:11 
>>> Ну тогда может через mpls over gre?
>>> Вообщем смысл такой, если не соединить ваши бордеры по igp, то анонсить
>>> придется разные сети в датацентрах. Теряется резервирование.
>> Можно поподробнее про mpls over gre - что мне это даст?
> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide...

Можно с одного ДЦ (основного) анонсить /24, а со второго (резервного) /23 , при пропадании анонсов первого - все уйдет на второй.


"BGP-резервирование"
Отправлено fantom , 23-Ноя-11 13:12 
>>>> Ну тогда может через mpls over gre?
>>>> Вообщем смысл такой, если не соединить ваши бордеры по igp, то анонсить
>>>> придется разные сети в датацентрах. Теряется резервирование.
>>> Можно поподробнее про mpls over gre - что мне это даст?
>> http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide...
> Можно с одного ДЦ (основного) анонсить /24, а со второго (резервного) /23
> , при пропадании анонсов первого - все уйдет на второй.

При этом разные провы или нет - значения не имеет.


"BGP-резервирование"
Отправлено universite , 25-Ноя-11 00:20 

> Можно с одного ДЦ (основного) анонсить /24, а со второго (резервного) /23
> , при пропадании анонсов первого - все уйдет на второй.

И анонс с резервного бордера стоит засунуть в бэкапное коммьюнити.