[Алексей Андриянов]

Здравствуйте, уважаемые коллеги, помогите пожалуйста начинающему админу.

 

Цель: получить AS и управлять входящим трафиком, перекидывая или распределяя его между двумя аплинками.

 

Сначала вкратце опишу ситуацию:

 

1. Оборудование, поддерживающее BGP есть.

2. Требования RIPE NCC к получателю AS удовлетворены: имеем 2 PA-диапазона /24 и /27, и 2 подключения к LIR-ам, выдавшим эти адреса. Диапазон /27 в АС нам не очень нужен, и при необходимости мы можем от него отказаться.

3. С обоими LIR есть договоренность о том, чтобы посодействовать получению нами АС, но оба они почему-то плохо представляют себе эту процедуру, и какие адреса в эту АС можно и стоит влкючать (PI или PA).

4. Для нас предпочтительнее было бы остаться на текущих PA-адресах, хотя бы чтобы заново не перенастраивать везде адреса.

 

Получилось так, что прояснить непонятные моменты больше практически негде. Возникли следующие конкретные вопросы, но был бы очень благодарен и за общий совет - что делать в такой типовой ситуации, в правильном ли направлении мы двигаемся? Я не жду, что кто-то очень добрый ответит на все вопросы, но надеюсь, что соберу кое-какую информацию "с миру по нитке".

 

Теперь, собственно, конкретные вопросы:

 

1. Могут ли входить в AS префиксы длинее 24 бит, или ограничение установлено просто на минимальное количество адресов в ней?

2. Должны ли мы получать PI-адреса, или при наличии доброй воли LIR PA-адреса не проблема?

2.1 Что значит фраза, сказанная в FAQ "...не стоит разрешать клиенту анонсировать адреса из Вашего блока другим провайдерам, могут возникнуть проблемы с прохождением анонсов специфик или Вы получите нежелательный трафик"?

Имеется ввиду анонс специфики для нашего PA-диапазона и нежелательный BGP-трафик?

2.2 И какого рода проблемы с этим анонсом? Настолько ли они серьезны, чтобы LIR не захотел анонсировать наш поддиапазон?

3. Если все же PA, то какой из 2 LIR должен подавать заявку на АС, или это может делать любой из них? Но должно же быть между ними какое-то взаимодействие, ведь оба диапазона попадают в AS?

4. Если все же PI, то можно ли на пальцах объяснить, каким образом входящие в АС адреса могут не быть "globally routable"? Или все зависит от длины префикса и количества памяти под таблицы на магистральных маршрутизаторах? Если да, то в нашем случае (/24) не будет разницы между PI и PA в плане связности? Или смысл в том, что в случае PA пакеты при потере динамического маршрута все равно дойдут по агрегированному?

5. Должен ли будет LIR, зарегистрировавший AS потом подтверждать изменение анонсируемых маршрутов, или это можно будет делать самостоятельно?

 

Спасибо заранее за ваши ответы!

[mt6561]

Добрый день!

 

Да, все это возможно и относительно несложно.

 

PA придется все поотдавать, а вместо них получить свой блок PI. Потому как аннонсирование чужого PA через другой аплинк приводит к куче глюков.

 

К AS могут быть привязаны блоки любого размера, но на практике блоки менее 256 адресов (/24) в глобальной сети не маршрутизируются.

 

AS, как и PI, регистрируется и отдается Вам, для управления ей не надо ничего от LIR'а, который ее регистрировал. Более того, LIR участвует в регистрации PI/AS только на этапе самой регистрации, потом LIR никакого отношения к объектам не имеет.

 

Получить PI/AS можно у любого LIR, не только у того, кто обеспечивает доступ в Интернет, например, у нас :)

 

Стучитесь в аську 5272901, звоните +7 495 7256396, проконсультируем, поможем обязательно!

 

Здравствуйте, уважаемые коллеги, помогите пожалуйста начинающему админу.

 

Цель: получить AS и управлять входящим трафиком, перекидывая или распределяя его между двумя аплинками.

 

Сначала вкратце опишу ситуацию:

 

1. Оборудование, поддерживающее BGP есть.

2. Требования RIPE NCC к получателю AS удовлетворены: имеем 2 PA-диапазона /24 и /27, и 2 подключения к LIR-ам, выдавшим эти адреса. Диапазон /27 в АС нам не очень нужен, и при необходимости мы можем от него отказаться.

3. С обоими LIR есть договоренность о том, чтобы посодействовать получению нами АС, но оба они почему-то плохо представляют себе эту процедуру, и какие адреса в эту АС можно и стоит влкючать (PI или PA).

4. Для нас предпочтительнее было бы остаться на текущих PA-адресах, хотя бы чтобы заново не перенастраивать везде адреса.

 

Получилось так, что прояснить непонятные моменты больше практически негде. Возникли следующие конкретные вопросы, но был бы очень благодарен и за общий совет - что делать в такой типовой ситуации, в правильном ли направлении мы двигаемся? Я не жду, что кто-то очень добрый ответит на все вопросы, но надеюсь, что соберу кое-какую информацию "с миру по нитке".

 

Теперь, собственно, конкретные вопросы:

 

1. Могут ли входить в AS префиксы длинее 24 бит, или ограничение установлено просто на минимальное количество адресов в ней?

2. Должны ли мы получать PI-адреса, или при наличии доброй воли LIR PA-адреса не проблема?

2.1 Что значит фраза, сказанная в FAQ "...не стоит разрешать клиенту анонсировать адреса из Вашего блока другим провайдерам, могут возникнуть проблемы с прохождением анонсов специфик или Вы получите нежелательный трафик"?

Имеется ввиду анонс специфики для нашего PA-диапазона и нежелательный BGP-трафик?

2.2 И какого рода проблемы с этим анонсом? Настолько ли они серьезны, чтобы LIR не захотел анонсировать наш поддиапазон?

3. Если все же PA, то какой из 2 LIR должен подавать заявку на АС, или это может делать любой из них? Но должно же быть между ними какое-то взаимодействие, ведь оба диапазона попадают в AS?

4. Если все же PI, то можно ли на пальцах объяснить, каким образом входящие в АС адреса могут не быть "globally routable"? Или все зависит от длины префикса и количества памяти под таблицы на магистральных маршрутизаторах? Если да, то в нашем случае (/24) не будет разницы между PI и PA в плане связности? Или смысл в том, что в случае PA пакеты при потере динамического маршрута все равно дойдут по агрегированному?

5. Должен ли будет LIR, зарегистрировавший AS потом подтверждать изменение анонсируемых маршрутов, или это можно будет делать самостоятельно?

 

Спасибо заранее за ваши ответы!

[Smoke]

На фоне флейма в regional-russia@ripe.net очень актуальный пост и ответ от кандидата в executive board RIPE :).

 

Политика и коммерция - рука об руку.

[AN111]

AS, как и PI, регистрируется и отдается Вам, для управления ей не надо ничего от LIR'а, который ее регистрировал. Более того, LIR участвует в регистрации PI/AS только на этапе самой регистрации, потом LIR никакого отношения к объектам не имеет.

Ну вообще то за PI и AS для PI LIR получит дополнительные score, что может повлиять на сумму оплаты LIR'ом услуг RIPE в следующем году...

 

Так что и LIR может попасть на деньги за получение PI и доп. AS.

[[Eagle]]

Можно поконкретнее о глюках, которые возникают при анонсировании PA через другого аплинка? Не наблюдал ни одного пока.

[Smoke]

Вопрос в том от кого вы анонсируете эти сети. Если от хозяина сети то фильры по AS-PATH вам помешают. именно эту проблему PI видимо и должны решать (мультихоминг сетей не являющихся LIR). IMHO - полномочия выдачи PI стоило оставить за RIR.

Изменено 3 мая, 2007 пользователем Smoke

[MrBear]

полномачия

А как звучит! Чистый Фройд... :)

[[Eagle]]

Вопрос в том от кого вы анонсируете эти сети. Если от хозяина сети то фильры по AS-PATH вам помешают.

Давайте конкретнее. Есть AS. В чем принципиальная разница, какой блок адресов привязан к ней: PI или PA ? У ибоих апстримов в фильтрах по AS-PATH естественно разрешена данная AS. И что здесь помешает?

[ptpending]

AS, как и PI, регистрируется и отдается Вам, для управления ей не надо ничего от LIR'а, который ее регистрировал. Более того, LIR участвует в регистрации PI/AS только на этапе самой регистрации, потом LIR никакого отношения к объектам не имеет.

Ну вообще то за PI и AS для PI LIR получит дополнительные score, что может повлиять на сумму оплаты LIR'ом услуг RIPE в следующем году...

 

Так что и LIR может попасть на деньги за получение PI и доп. AS.

Глюк заключается в том что mt6561 не получит денег за регистрацию PI через свой LIR. Обидно однако. Все остальные возможные глюки зависят от квалификации upstream и LIR по совместительству.

[Алексей Андриянов]

Тогда интересует вопрос о недостатках PI-адресов.

 

Можно ли на пальцах объяснить, каким образом входящие в АС PI-адреса могут не быть "globally routable"? Это просто имеется ввиду, что нужно обязательно поднимать BGP? Или все зависит от длины префикса и количества памяти под таблицы на магистральных маршрутизаторах? Если да, то в нашем случае (/24) не будет разницы между PI и PA в плане связности? Или смысл в том, что в случае PA пакеты при потере динамического маршрута все равно дойдут по агрегированному?

Есть ли смысл для увеличения надежности(связности) брать диапазон шире чем /24 (/23 или /22)? И насколько RIPE более серьезно относится к заявкам на PI, чем на PA - я слышал, что они там реально жмутся на PI-адреса и требуют правдивого обоснования их последующего использования?

[Smoke]

Просто интересно.

Покажите AS на PA. Отдать свой трафик конкуренту.. чтоб кастомеру был мультихоминг. Свой канал останется backup, а бабло пошло мимо.

Есть реальные включения ?

[Smoke]

Тогда интересует вопрос о недостатках PI-адресов.

 

Можно ли на пальцах объяснить, каким образом входящие в АС PI-адреса могут не быть "globally routable"? Это просто имеется ввиду, что нужно обязательно поднимать BGP? Или все зависит от длины префикса и количества памяти под таблицы на магистральных маршрутизаторах? Если да, то в нашем случае (/24) не будет разницы между PI и PA в плане связности? Или смысл в том, что в случае PA пакеты при потере динамического маршрута все равно дойдут по агрегированному?

Есть ли смысл для увеличения надежности(связности) брать диапазон шире чем /24 (/23 или /22)? И насколько RIPE более серьезно относится к заявкам на PI, чем на PA - я слышал, что они там реально жмутся на PI-адреса и требуют правдивого обоснования их последующего использования?

 

При мультихоминге без BGP не обойтись. дырку в блоке адресов ради вашего анонса не уверен что аплинк сделает. самое лёгкое и дорогое - стать LIR. иначе вы возможность рулить трафиком не получите. PI - решает эту проблему но это уже к М.Тульеву. Он продаёт независимость :). При этом PI ломает парадигму RIPE - логика рушится. поэтому если вы провайдер думайте сразу о LIR.

Изменено 4 мая, 2007 пользователем Smoke

[mr.Scamp]

При этом PI ломает парадигму RIPE - логика рушится. поэтому если вы провайдер думайте сразу о LIR.

А можно ли поподробнее?

[Smoke]

Это просто IMHO

Им просто удобнее делегировать блок LIRу и забыть что будет внутри агрегата.

[ptpending]

Просто интересно.

Покажите AS на PA. Отдать свой трафик конкуренту.. чтоб кастомеру был мультихоминг. Свой канал останется backup, а бабло пошло мимо.

Есть реальные включения ?

Обычно мультихомятся клиенты достаточно серьёзные, или несколько услуг берут, и сидят на анлиме

таких спокойно к другим можно отпустить параллельно и сеть с АС отпилить.

[ptpending]

Тогда интересует вопрос о недостатках PI-адресов.

 

Можно ли на пальцах объяснить, каким образом входящие в АС PI-адреса могут не быть "globally routable"? Это просто имеется ввиду, что нужно обязательно поднимать BGP? Или все зависит от длины префикса и количества памяти под таблицы на магистральных маршрутизаторах? Если да, то в нашем случае (/24) не будет разницы между PI и PA в плане связности? Или смысл в том, что в случае PA пакеты при потере динамического маршрута все равно дойдут по агрегированному?

Есть ли смысл для увеличения надежности(связности) брать диапазон шире чем /24 (/23 или /22)? И насколько RIPE более серьезно относится к заявкам на PI, чем на PA - я слышал, что они там реально жмутся на PI-адреса и требуют правдивого обоснования их последующего использования?

 

При мультихоминге без BGP не обойтись. дырку в блоке адресов ради вашего анонса не уверен что аплинк сделает. самое лёгкое и дорогое - стать LIR. иначе вы возможность рулить трафиком не получите. PI - решает эту проблему но это уже к М.Тульеву. Он продаёт независимость :). При этом PI ломает парадигму RIPE - логика рушится. поэтому если вы провайдер думайте сразу о LIR.

с одной /24 даже с BGP рулить особо не получится, только резервирование канала, довольно медленное переключающееся. Так что сладость PI это такой-же миф как и злобные LIR которые будут перекрывать с PA. Только доходят до этого когда уже получаеют его. Для промежуточного решения в RIPE придумали SUB-ALLOCATION для PA. Единственный разумный смысл PI - некоторая халявность, замеченый в основном UA - этим пользуются мелкие провайдеры которые не в состоянии заработать 50 евроцентов в год на каждый выданный им адрес из блока PA.

Изменено 12 мая, 2007 пользователем ptpending

[Yokodzun]

с одной /24 даже с BGP рулить особо не получится, только резервирование канала, довольно медленное переключающееся.

А можно подробнее про "медленное переключение"?

Ну и засада с мелкими PI может быть при работе с аплинками, которые не пущают сети мельче /23.

Но в УА таких вроде нету.

[poweruser]

подскажите неопытному что значит

Надо заметить, что получение PI-адресов не означает, что Вам будет доступна любая часть Internet. Маршрутизация этих адресов, возможно, потребует дополнительной платы. Со временем маршрутизация сравнительно небольшого PI-пространства в Internet может оказаться невозможной.

кому и как платят за эту маршрутизацию?

Изменено 11 мая, 2007 пользователем poweruser

[ptpending]

подскажите неопытному что значит

Надо заметить, что получение PI-адресов не означает, что Вам будет доступна любая часть Internet. Маршрутизация этих адресов, возможно, потребует дополнительной платы. Со временем маршрутизация сравнительно небольшого PI-пространства в Internet может оказаться невозможной.

кому и как платят за эту маршрутизацию?

Этот миф культивируется с времён 1995 года, когда у Sprint переполнилась память в core роутерах и они отфильтровали всё что меньше /19. С тех пор LIRам начали давать в основном /19 и только в этом году стали давать меньше чем /20. В то время как под PI очень часто давали /24 или /23. В результате когда у какого-нибудь магистрала опять кончится память и тогда он снова может отфильтровать /24.

Вот кстати отголоски мифа - http://www.ripe.net/ripe/maillists/archive...6/msg00026.html

Изменено 11 мая, 2007 пользователем ptpending

[ptpending]

с одной /24 даже с BGP рулить особо не получится, только резервирование канала, довольно медленное переключающееся.

А можно подробнее про "медленное переключение"?

Ну и засада с мелкими PI может быть при работе с аплинками, которые не пущают сети мельче /23.

Но в УА таких вроде нету.

Медленное переключение - дело в том что даже если в таблице bgp есть 2 маршрута на вас, то в таблице маршрутов установлен только один из них, лучший, т.к. префикс одинаковый а длина разная (выход через разных ISP). В результате для того чтобы все BGP маршрутизаторы всего интернета удалили ваш старый маршрут пересчитали и добавили новый требуется время 5-10 минут. После 2-х минутного пропадания вам начнут обрывать все телефоны всякие домашние пользователи и другая мелочь, которая потом развоняется на всех форумах о том что вы падали такого-то числа и у него завис char в RPG которого замочили.

Изменено 11 мая, 2007 пользователем ptpending

[Yokodzun]

Медленное переключение - дело в том что даже если в таблице bgp есть 2 маршрута на вас, то в таблице маршрутов установлен только один из них, лучший, т.к. префикс одинаковый а длина разная (выход через разных ISP). В результате для того чтобы все BGP маршрутизаторы всего интернета удалили ваш старый маршрут пересчитали и добавили новый требуется время 5-10 минут. После 2-х минутного пропадания вам начнут обрывать все телефоны всякие домашние пользователи и другая мелочь, которая потом развоняется на всех форумах о том что вы падали такого-то числа и у него завис char в RPG которого замочили.

Сходимость BGP 5-10минут? Нупрямотаки!!!!

А собственно, какая альтернатива?

[ptpending]

Что-то я непонял вашего вопроса, попробуйте - выпустите сетку

уберите её, выпустите снова. Увидите.

[Yokodzun]

Что-то я непонял вашего вопроса, попробуйте - выпустите сетку

уберите её, выпустите снова. Увидите.

Ну собсно так и делаю, потому и удивился :-)

По моим наблюдениям, гораздо быстрее.

[ptpending]

агрегат параллельно анонсируете ?

[Yokodzun]

агрегат параллельно анонсируете ?

Ээээ.... Не понял, поясните плс.