LINUX.ORG.RU
Форум — Admin  

Резервная площадка, один /24 PI блок у разных провайдеров

 , ,


1

3

Вопрос по организации работы BGP.

Есть две площадки с оборудованием в разных странах - «А» и «Б». Площадка «Б» работает в роли бекапа площадки «А», то есть все обращения из инета идут на площадку «А» по умолчанию.

Также есть PI блок /24 IPv4 адресов и ASN. Стоит задача сделать так, чтобы в случае отказа площадки «А» все обращения из инета попадали на площадку «Б», по тем же внешним IPv4 адресам из данного PI блока.

Каким образом это возможно реализовать с помощью BGP? Мне известно как это сделать при помощи /23 PI блока, разделив анонс на два /24 префикса, но в наличии только /24 блок.

★★★

В BGP нет специальных механизмов для реализации Anycast BGP, вы просто объявляете ваш префикс с каждого из сайтов. А далее, кроме BGP community no-export и AS PREPEND, у вас нечего нет.

Объявите ваш префикс через сайт В с длинным AS PREPEND, это конечно не 100% гарантия, что не какой трафик некогда не пойдёт через сайт В, но уже что-то.

Есть RFC 4786: Operation of Anycast Services, можно ещё с ним ознакомится.

P/S/ Может быть кто-то ещё что-то придумает, было интересно почитать.

ZANSWER ★
()

Разве что скрипты, кладущие один анонс и поднимающие другой. Но если будут активны два одновременно, будет не здорово.

AS ★★★★★
()

Анонсировать с обеих площадок, а потом уже разруливать трафик. Могу подробнее, если интересно, расписать варианты.

TOXA ★★
()
Ответ на: комментарий от FreeBSD

Это фундаментальная проблема архитектуры сети Интернет, отдельно взятая AS не может влиять на политику маршрутизации другой AS. Для этого просто нет действенных механизмов.

Поэтому, всё, что мы имеем, это скромный набор трюков, а не гарантированный механизм.

ZANSWER ★
()
Ответ на: комментарий от TOXA

Зал в нетерпение, он ожидает от вас всеобъемлющих подробностей.

Вы предлагаете иной способ, кроме уже названных механизмов, для переопределения политики маршрутизации транзитных AS?

ZANSWER ★
()

Узнайте у провайдера резервной площадки наличие у него в настройках BGP backup коммьюнити (некоторые пишут такую инфу в своем типа RIPE NCC и доступна она через запрос whois ASХХХХ) и объявите префикс на резервной площадке с этой коммьюнити. По идее должно работать. Но бывают глюки - приходится иногда сбрасывать BGP сессию резервного линка, после аварии и восстановления основного.
а так скриптом можно это сделать, тупо запускать или останавливать демон маршрутизации BGP.

Vlad-76 ★★★★
()
Ответ на: комментарий от ZANSWER

Я бы предложил использовать оба активных анонса для организации anycast и дальше уже разруливать трафик, который придет в AS. Можно задействовать хитрый NAT + скрипты на здоровье основной площадки. Если есть возможность - можно организовать VRRP на стороне сервисов, чтобы использовать failover площадок.

TOXA ★★
()
Ответ на: комментарий от Vlad-76

Вариант выглядит интересно и точно стоит того, чтобы его попробовать.

Для тех кому интересно, как это работает, как должно работать по крайней мере, RFC 4264: BGP Wedgies

ZANSWER ★
()
Ответ на: комментарий от TOXA

В том то и дело, что автору требуется, чтобы трафик не приходил в AS через площадку В, кроме случая, когда площадка А более недоступна.

ZANSWER ★
()
Ответ на: комментарий от ZANSWER

Во всех случаях(кроме ручного переключения, читай healthcheck-скрипт) придется настраивать anycast-like поведение. Лучшим выходом будет, как посоветовал ZANSWER :

Объявите ваш префикс через сайт В с длинным AS PREPEND, это конечно не 100% гарантия, что не какой трафик некогда не пойдёт через сайт В, но уже что-то.

TOXA ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin