Могут ли быть подвохи в выделении PI-блока IP адресов?

[ivan77]

В смысле действительно ли они роутиться нормально везде в И-нете будут...

И есть ли еще варианты сделать 2 внешних канала?

[Bushi]

В смысле действительно ли они роутиться нормально везде в И-нете будут...

И есть ли еще варианты сделать 2 внешних канала?

 

В принципе даже и PA нормально роутятся. Если префикс сети не больше /21. Более мелкие сети могут фильтроватся на роутерах магистральных провайдеров. Если нормально BGP настроите, AS зарегистрируете и с провайдерами договоритесь, то какие могут быть подвохи?

[Andrew40]

В смысле действительно ли они роутиться нормально везде в И-нете будут...

Будут нормально, если:

1. Вас подключат с этими адресами вообще.

2. А могут подключить, только в том случае, если это большой пул, иначе многие провайдеры (магистральные, а те, кто вас подключать будет) фильтруют подобные записи для ограничения размеров таблиц маршрутизации.

3. Вы договоритесь с провайдерами и настроите BGP.

И есть ли еще варианты сделать 2 внешних канала?

Сколько угодно. А что требуется от 2-х каналов в смысле независимости? Если честный независимый IP адрес, то нет. А если стандартные услуги, то да.

[boykov]

есть

обязательно необходимо договариваться с обоими провайдерами о маршрутизации вашей сети. Они должны анонсить маршруты до вас через себя. Плюс -- если вы хотите управлять трафиком сами, то нужно получать свою AS и учить BGP.

[ivan77]

Не понял насчёт подключат - вопрос их получить, но это надо просто с LIR'ом договориться.

Нам реально нужно иметь много реальных IP (разные сервера, внешний доступ, произвольное оборудование наших клиентов, IP шлюзы и т.д.).

И сделать при этом резервирование канала.

Оба провайдера анонсируют наш AS (почти договорились).

Но вот насчёт фильтрации сетей /24 на магистральных маршрутизаторах...

Именно про этот "подвох" я и спрашивал.

Если наши провайдеры без проблем нас анонсируют - будут ли у наших клиентов проблемы с интернетом?!

[Bushi]

Не понял насчёт подключат - вопрос их получить, но это надо просто с LIR'ом договориться.

Нам реально нужно иметь много реальных IP (разные сервера, внешний доступ, произвольное оборудование наших клиентов, IP шлюзы и т.д.).

И сделать при этом резервирование канала.

Оба провайдера анонсируют наш AS (почти договорились).

Но вот насчёт фильтрации сетей /24 на магистральных маршрутизаторах...

Именно про этот "подвох" я и спрашивал.

Если наши провайдеры без проблем нас анонсируют - будут ли у наших клиентов проблемы с интернетом?!

 

Насколько я знаю, минимальный блок адресов PI, который можно получить - 8 сетей класса C ( префикс /21). То есть если у Вас адреса PI - проблем не будет. Если у вас адреса PA (Provider Agregated), то по договоренности с провайдером, которому принадлежат эти адреса, Вы их так же можете проанонсировать, но в случае фильтрации маршрутов на магистральных роутерах трафик к Вам пойдет не по кратчайшему (или выгодному для Вас) пути, а через каналы провайдера, которому собственно и принадлежит блок адресов PA. То есть связность сетей в случае фильтрации все равно не нарушится, однако полного Provider Independent не получится.

[jab]

Насколько я понимаю, в последнее время RIPE'ы PI блоки неLIR'ам практически не дают, во избежание известных проблем в будущем. Разве что по блату выпросить... но смысл ? Ну а LIR'ы подобных вопросов

не задают afaik.

[Bushi]

Насколько я понимаю, в последнее время RIPE'ы PI блоки неLIR'ам практически не дают, во избежание известных проблем в будущем. Разве что по блату выпросить... но смысл ? Ну а LIR'ы подобных вопросов

не задают afaik.

 

Делайте заявку на PI-адреса и направьте ее LIR'у. LIR обязан перенаправить ее в RIPE.

[jab]

:-) Ну разговор-то был не про меня. Я-то уж с RIPE и сам как-нибудь договорюсь.

А вот тем, кто такие вопросы задает как в сабджекте - скорее всего предложат

стать LIR и за свой /19 денюг платить. Потому как выданная в прошлом

куча неагреггируемых PI блоков - это как заноза в заднице. :-)

[ivan77]

:-) Ну разговор-то был не про меня. Я-то уж с RIPE и сам как-нибудь договорюсь.

А вот тем, кто такие вопросы задает как в сабджекте - скорее всего предложат

стать LIR и за свой /19 денюг платить. Потому как выданная в прошлом

куча неагреггируемых PI блоков - это как заноза в заднице. :-)

То, что RIPE общается только с LIR - ясно. Согласно RIPE-324 PI адреса выделяются, но только если это хорошо обоснованно.

"куча неагреггируемых PI блоков - это как заноза в заднице. :-)" - я прекрасно это понимаю, но что нам-то делать?! Нам нужны

1) реальные IP

2) чтобы AS на этих IP анонсировали 2 (ДВА) совсем разных провайдера. И дружно их обслуживали. Зачем нам LIR?!

Кстати, там же написано, что минимальный блок как раз /21, а не /19 :)

[MrBear]

Потому как выданная в прошлом куча неагреггируемых PI блоков - это как заноза в заднице. :-)

 

В том числе и потому, что запрашивают их обычно небогатые борцы за тотальную справедливость, чаще всего слабо знакомые с BGP. :))

[jab]

1) реальные IP

2) чтобы AS на этих IP анонсировали 2 (ДВА) совсем разных провайдера. И дружно их обслуживали. Зачем нам LIR?!

Кстати, там же написано, что минимальный блок как раз /21, а не /19 :)

 

Хотелось бы сначала узнать, что сказали NOC'и этих провайдеров на тему

организации с Вами пограничного взаимодействия ?

[jab]

Потому как выданная в прошлом куча неагреггируемых PI блоков - это как заноза в заднице. :-)

 

В том числе и потому, что запрашивают их обычно небогатые борцы за тотальную справедливость, чаще всего слабо знакомые с BGP. :))

 

А я-то думал что это из-за того, что в кошках память дорогая. :-)

[MrBear]

А я-то думал что это из-за того, что в кошках память дорогая. :-)

 

1. Кингстоновская от бытовухи немногим отличается.

2. Держащих полную таблицу по пальцам пересчитать.

[ivan77]

jab, основной NOC сказал - вперёд. Со вторым пока не связывались, но тоже, думаю, проблем не будет.

[jab]

jab, основной NOC сказал - вперёд. Со вторым пока не связывались, но тоже, думаю, проблем не будет.

 

Я бы все-таки связался со вторым до того как предпринимать какие-либо действия.

Причем Вы должны обоим NOC'ам описать подробно то что Вы хотите получить

в результате...

[jab]

А я-то думал что это из-за того, что в кошках память дорогая. :-)

1. Кингстоновская от бытовухи немногим отличается.

2. Держащих полную таблицу по пальцам пересчитать.

 

Так тут не в самой памяти дело, а в том, что ее много-то и не поставишь...

[MrBear]

Так тут не в самой памяти дело, а в том, что ее много-то и не поставишь...

 

Так семитысячники скоро будут на развес продаваться, стараниями Павла Владимировича :), там памяти на полную таблицу с лихвой хватает - какие проблемы?

[ivan77]

jab, для того, чтобы определиться со вторым NOC, мне нужна схема соединения провайдеров Москвы. Я ее видел полгода назад, но потерял... Поэтому сейчас я не знаю, кому отдать предпочтение (у нас по оптике присутствует много операторов).

[jab]

Так семитысячники скоро будут на развес продаваться, стараниями Павла Владимировича :), там памяти на полную таблицу с лихвой хватает - какие проблемы?

 

Ну... Если Вы полагаете, что Павел Владимирович занимает хоть сколько-нибудь

заметную долю мирового рынка магистральных маршрутизаторов, то я тут

спорить не буду... Может и правда это очень просто - проапгрейдить купленное

в незапамятные времена и до сих пор работающее на семитысячники... :-)

[leiden]

jab, для того, чтобы определиться со вторым NOC, мне нужна схема соединения провайдеров Москвы. Я ее видел полгода назад, но потерял... Поэтому сейчас я не знаю, кому отдать предпочтение (у нас по оптике присутствует много операторов).

 

МАМА!!! Люди - не давайте ему PI!

Ну пожалуйста! Ну нельзя этого делать! :)

Как можно давать такие адреса человеку, который думает, что существует "схема соединения провайдеров Москвы" :)

 

Специально для ivan77 - схема соединения провайдеров Москвы устареет сразу в момент ее построения. Поэтому ее нет в природе. Потому что благодаря большому количеству разнообразной оптики, а также зданиям на Бутлерова, Сущевском Валу, Шаболовке и прочим аналогичным - установление и разрыв соединения двух операторов - не представляет никакой сложности. И, несмотря на то, что моя непосредственная работа напрямую связана с тем, чтобы я знал ВСЕ соединения значимых операторов в Москве - мне это уже два года стабильно не удается.

[Tail]

1. особых проблем при грамотно заполненной заявке в RIPE при выделении PI блока нет. не раз получали блоки - переписка с RIPE (через LIR) сводилась к подаче заявки, одного уточняющего письма от RIPE и, собственно, уведомлением от RIPE object created :)

2. проблем с маршрутизацией блоков /24 не существует. мы проработали больше года на /24 и никакого дискомфорта не испытывали. сейчас получили /22.

3. если нужен один основной линк а другой под бекап или только вход (без исхода) то нет нужды держать ful view BGP. потянет любая 25 кошка %) если не загнется от нагрузки трафиком, естессно %)

[ivan77]

leiden, хорошо. Меня интересуют зарубежные каналы. Тоже, у всех их навалом и все без проблем переключаются? ;)

 

Tail, а что написать в %NETWORK DESCRIPTION%? если я напишу про

двух провайдеров - достаточно ли?!

 

цитирую:

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 на http://www.ripe.net/rs/ipv4policy.html ссылаются на rfc1930

(образца 1996-го года) у которого есть section 7 - "One prefix, one origin AS".

Кроме того, до последнего времени тот же RIPE наличие more specific роутов

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

отношению к сему вопросу и _нигде_ об этом не пишут, ну не ^&*^*&^?

Но .. в RIPE регионе 17% route-object-ов имеют более одного origin-а. Да, из

них часть это просто ошибки, но процентов 10% это реально работающий

multihoming на этом принципе. Тот же eBay, например, multihome-ится через

more specific.