On Thu, Nov 01, 2001 at 10:05:00AM +0300, Alexey L. Burlakov wrote:
>
> Доброе время суток, уважаемые коллеги!
> Возник у меня такой вот вопрос.
> Есть (точнее очень скоро будет) сеть , и 2 аплинка, через спутник.
> Один приземляется в России, второй в штатах.
> Мне очень не хочется каждый раз перепрописывать таблицу
> маршрутизации после того, как я буду вносить изменения.
> Пока я смог найти только один выход, это регистрация в RIPE.NET AS
> Может быть уважаемые коллеги смогут подсказать что-либо еще?
> Или вариантов больше никаких?
I.e. у вас есть сеть, которая будет multihomed к двум uplink-ам и вам требуется
максимальный resilence на случай аварий одного из каналов? I.e. вы не
собираетесь транзитить через себя прочие AS-ы.
Если так, то у вас есть два граничных варианта:
1. Правильный-по-старому - получить от RIPE/ARIP PI/PA кусок адресов
+ автономную систему, и строить с обоими uplink-ами BGP
взаимодействие.
2. Правильный-по-новому - попросить одного из ваших uplink-ов создать
в рамках его allocation-а more specific route object и оториджини-
ровать его от своего AS-а, попросить второго вашего uplink-а создать
еще один route object на тот же inetnum range и оториджинировать
его от своего AS-а. Таким образом этот more specific будет виден
в миру от двух разных origin AS-ов. Далее вы строите с вашими
uplink-ами eBGP на приватных as-num-ах, или чтото из IGP дабы
соотв. uplink прекращал анонс соотв. more specific при аварии
канала вы-uplink.
Есть еще два промежуточных варианта - не брать AS но брать PI, брать отдельный
AS но не брать PI.
Теперь касаемо pros and cons обоих вариантов:
первый - все хорошо, но как минимум RIPE в последнее время не любит давать PI
и AS под multihoming без подробного объяснения почему вариант 2 не подходит.
Причины почему RIPE это не любит - тема отдельного разговора.
второй - нет ни одного public документа RIR-ов или RFC который не просто о
писывал этот метод, но хотя бы упоминал о нем в ключе Best Practice. Хуже того,
текущий ripe-185 ("IPv4 and ASN Policies in the RIPE NCC Service Region") и
working draft на ссылаются на rfc1930
(образца 1996-го года) у которого есть section 7 - "One prefix, one origin AS".
Кроме того, до последнего времени тот же RIPE наличие more specific роутов
клеймил под флагом борьбы за агрегативность. А тут вдруг они меняют свое
отношению к сему вопросу и _нигде_ об этом не пишут, ну не ^&*^*&^?
Но .. в RIPE регионе 17% route-object-ов имеют более одного origin-а. Да, из
них часть это просто ошибки, но процентов 10% это реально работающий
multihoming на этом принципе. Тот же eBay, например, multihome-ится через
more specific.
Anyway, решать вам.
Btw, с месяц назад в lir-wg@ripe.net и routing-wg@ripe.net была большая
дискуссия по поводу multihoming-а, если кому интерестно ее можно найти у
RIPE-а на сайте, Subject-ы "more specific routes in today reality" и
"Multihoming - Resilience or Independence".
--
Regards,
Vladimir.
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
