Hello! Столкнулся с проблемой: есть /19 под некой AS X. Планируется построить автономную площадку в другом городе, которая не будет связана с инфраструктурой AS X (никак). При этом, организация LIR и строит эту площадку для себя. Понимаю, что на эту площадку нужно получать AS, но, как быть с адресами? Заказывать и их или выкусывать из /19 (есть возможность разбить /19 на два /20). Что в этом случае говорит RIPE? Как сделать "не криво"? -- Edward Melnik. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 01:19:38AM +0300, Edward Melnik wrote: Приветствую,
есть /19 под некой AS X. Планируется построить автономную площадку в другом городе, которая не будет связана с инфраструктурой AS X (никак). При этом, организация LIR и строит эту площадку для себя. Понимаю, что на эту площадку нужно получать AS, но, как быть с адресами? Заказывать и их или выкусывать из /19 (есть возможность разбить /19 на два /20). Что в этом случае говорит RIPE? Как сделать "не криво"?
А почему бы в этом случае не анонсить половину /19 из другого места из-под уже существующего as-num ?
-- Edward Melnik.
-- Andrey Elperin Internet Data Center "ColoCALL" =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 12:20:26PM +0300, Andrey Elperin wrote:
On Sun, Sep 11, 2005 at 01:19:38AM +0300, Edward Melnik wrote:
Приветствую,
есть /19 под некой AS X. Планируется построить автономную площадку в другом городе, которая не будет связана с инфраструктурой AS X (никак). При этом, организация LIR и строит эту площадку для себя. Понимаю, что на эту площадку нужно получать AS, но, как быть с адресами? Заказывать и их или выкусывать из /19 (есть возможность разбить /19 на два /20). Что в этом случае говорит RIPE? Как сделать "не криво"?
А почему бы в этом случае не анонсить половину /19 из другого места из-под уже существующего as-num ?
Т.е., инфраструктура AS X, под ней /20, а на другой площадке тоже будет AS X и другие /20. И при этом, они не связаны непосредственно между собой никак. И будет так работать? А то как-то не доводилось такого строить. Ведь, как будет вести себя маршрутизатор, видя два as-path к одной AS, но разным prefix'ам? А теперь приведу более реальный сценарий (который планируется): /19 разбивается на два /20. Первый /20 анонситься от AS X. Второй /20 разбивается на /24 и разъезжается по автономным площадкам и анонситься каждый из этих блоков от AS X. И так тоже будет работать? И не раком ли это? Я что-то потерялся, как это будет уживаться в маршрутизаторах + как это сделать правильно, относительно RIPE. -- Edward Melnik. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 12:34:41PM +0300, Edward Melnik wrote:
И будет так работать? А то как-то не доводилось такого строить. Ведь, как будет вести себя маршрутизатор, видя два as-path к одной AS, но разным prefix'ам?
Будет маршрутизировать :) Только нужно будет создать в ripe-db соответствующий route object для каждого префикса.
А теперь приведу более реальный сценарий (который планируется): /19 разбивается на два /20. Первый /20 анонситься от AS X. Второй /20 разбивается на /24 и разъезжается по автономным площадкам и анонситься каждый из этих блоков от AS X. И так тоже будет работать? И не раком ли это? Я что-то потерялся, как это будет уживаться в
Лично с моей точки зрения - отнюдь не более раково, чем заводить для каждой такой площадки отдельный as-num.
маршрутизаторах + как это сделать правильно, относительно RIPE.
RIPE обычно озвучивает свою позицию как "не увеличивать количество префиксов в fullview", и именно с этой позиции предлагает всем брать PA-адреса у непосредственного аплинка (т.к. в этом случае в мир идет один анонс /19 или больше). Т.к. в данном случае от увеличения количества анонсов все равно никуда не деться - RIPE скорее всего займет позицию "не увеличивать энтропию", т.е. не выдавать несколько as-num там, где можно обойтись одним. -- Andrey Elperin =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, 11 Sep 2005, Andrey Elperin wrote:
On Sun, Sep 11, 2005 at 12:34:41PM +0300, Edward Melnik wrote:
И будет так работать? А то как-то не доводилось такого строить. Ведь, как будет вести себя маршрутизатор, видя два as-path к одной AS, но разным prefix'ам?
Будет маршрутизировать :)
Только нужно будет создать в ripe-db соответствующий route object для каждого префикса.
А теперь приведу более реальный сценарий (который планируется): /19 разбивается на два /20. Первый /20 анонситься от AS X. Второй /20 разбивается на /24 и разъезжается по автономным площадкам и анонситься каждый из этих блоков от AS X. И так тоже будет работать? И не раком ли это? Я что-то потерялся, как это будет уживаться в
Лично с моей точки зрения - отнюдь не более раково, чем заводить для каждой такой площадки отдельный as-num.
маршрутизаторах + как это сделать правильно, относительно RIPE.
RIPE обычно озвучивает свою позицию как "не увеличивать количество префиксов в fullview", и именно с этой позиции предлагает всем брать PA-адреса у непосредственного аплинка (т.к. в этом случае в мир идет один анонс /19 или больше). Т.к. в данном случае от увеличения количества анонсов все равно никуда не деться - RIPE скорее всего займет позицию "не увеличивать энтропию", т.е. не выдавать несколько as-num там, где можно обойтись одним.
А тут не обойтись... An Autonomous System (AS) is a group of IP networks run by one or more network operators with a single, clearly defined routing policy. У него ж площадки абсолютно не связаные. И у каждой, насколько я понял, будет именно свой clearly defined routing policy. Можно, конечно, neighbor x.x.x.x allowas-in но тогда одной из задач будет страхование от чужого криворучия. Я бы получал еще один ASN и разбивал PA. Против такого RIPE точно не будет протестовать. Главное - честно глядя им в глаза, объяснить ситуацию. Ну либо, если адресов мало или жадно - additional allocation. С PI - ну его в баню. Под одну организацию не дадут. Тем более под LIR. -- RAZ-UANIC RAZ-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 05:33:20PM +0300, Anton Turygin wrote: AT> On Sun, 11 Sep 2005, Andrey Elperin wrote: AT> AT> >On Sun, Sep 11, 2005 at 12:34:41PM +0300, Edward Melnik wrote: AT> >>И будет так работать? А то как-то не доводилось такого строить. AT> >>Ведь, как будет вести себя маршрутизатор, видя два as-path к одной AS, но AT> >>разным prefix'ам? AT> > AT> >Будет маршрутизировать :) AT> > AT> >Только нужно будет создать в ripe-db соответствующий route object для AT> >каждого префикса. AT> > AT> >>А теперь приведу более реальный сценарий (который планируется): AT> >>/19 разбивается на два /20. Первый /20 анонситься от AS X. AT> >>Второй /20 разбивается на /24 и разъезжается по автономным площадкам и AT> >>анонситься каждый из этих блоков от AS X. AT> >>И так тоже будет работать? AT> >>И не раком ли это? Я что-то потерялся, как это будет уживаться в AT> > AT> >Лично с моей точки зрения - отнюдь не более раково, чем заводить AT> >для каждой такой площадки отдельный as-num. AT> > AT> >>маршрутизаторах + как это сделать правильно, относительно RIPE. AT> > AT> >RIPE обычно озвучивает свою позицию как "не увеличивать количество AT> >префиксов в fullview", и именно с этой позиции предлагает всем AT> >брать PA-адреса у непосредственного аплинка (т.к. в этом случае в мир AT> >идет один анонс /19 или больше). Т.к. в данном случае от увеличения AT> >количества анонсов все равно никуда не деться - RIPE скорее всего AT> >займет позицию "не увеличивать энтропию", т.е. не выдавать несколько AT> >as-num там, где можно обойтись одним. AT> > AT> AT> AT> А тут не обойтись... AT> AT> An Autonomous System (AS) is a group of IP networks run by one or more AT> network operators with a single, clearly defined routing policy. AT> AT> У него ж площадки абсолютно не связаные. И у каждой, насколько я понял, AT> будет именно свой clearly defined routing policy. AT> AT> Можно, конечно, AT> neighbor x.x.x.x allowas-in AT> но тогда одной из задач будет страхование от чужого криворучия. AT> AT> Я бы получал еще один ASN и разбивал PA. Против такого RIPE точно не будет AT> протестовать. Главное - честно глядя им в глаза, объяснить ситуацию. AT> Ну либо, если адресов мало или жадно - additional allocation. С PI - ну AT> его в баню. Под одну организацию не дадут. Тем более под LIR. мне дали но это в чем-то подвиг :) -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Еды оставалось на полчаса =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, 11 Sep 2005, Alexander Trotsai wrote:
On Sun, Sep 11, 2005 at 05:33:20PM +0300, Anton Turygin wrote: AT> Я бы получал еще один ASN и разбивал PA. Против такого RIPE точно не будет AT> протестовать. Главное - честно глядя им в глаза, объяснить ситуацию. AT> Ну либо, если адресов мало или жадно - additional allocation. С PI - ну AT> его в баню. Под одну организацию не дадут. Тем более под LIR.
мне дали но это в чем-то подвиг :)
Я такого откаблукивать не умею. Видать, молод еще ;-) А в чем секрет? Бралось под что-то типа закрытой точки обмена? -- RAZ-UANIC RAZ-RIPE Technological Systems CJVC System Administrator =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 07:46:38PM +0300, Anton Turygin wrote: AT> On Sun, 11 Sep 2005, Alexander Trotsai wrote: AT> AT> >On Sun, Sep 11, 2005 at 05:33:20PM +0300, Anton Turygin wrote: AT> >AT> Я бы получал еще один ASN и разбивал PA. Против такого RIPE точно не AT> >будет AT> >AT> протестовать. Главное - честно глядя им в глаза, объяснить ситуацию. AT> >AT> Ну либо, если адресов мало или жадно - additional allocation. С PI - ну AT> >AT> его в баню. Под одну организацию не дадут. Тем более под LIR. AT> > AT> >мне дали AT> >но это в чем-то подвиг :) AT> > AT> AT> Я такого откаблукивать не умею. Видать, молод еще ;-) AT> AT> А в чем секрет? Бралось под что-то типа закрытой точки обмена? нет просто описал, что аннонсируется тут /19, а надо чтобы тут вообще никаким боком не было на момент когда брал, еще был документ имени райп, какие префиксы какую минимальную длину имеют - вот типа я и сказал, если порежу /19, так по вашему же документу ее и не примут, поэтому давайте мне /24 PI в AS8788 -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Часы бьют. Всех =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Alexander,
просто описал, что аннонсируется тут /19, а надо чтобы тут вообще никаким боком не было на момент когда брал, еще был документ имени райп, какие префиксы какую минимальную длину имеют - вот типа я и сказал, если порежу /19, так по вашему же документу ее и не примут, поэтому давайте мне /24 PI в AS8788
Во-вторых док-т и ныне там. А во-первых, как уже было замечено, AS тут еще можно попробовать сэкономить, но с адресами и анонсами все равно ничего не выгадаешь - адреса потратятся и анонс добавится. Потому по-моему все равно, будет он PA или PI. С идейной же точки зрения, на мой взгляд, "allocation'ы" для того и были придуманы, чтобы их анонсить целиком. И поэтому я вижу смысл в получении PI для сохранения идеи :) По-поводу разбивания на две /20 хотелось бы заметить, что когда-нть придется получать следующий allocation и продемонстировать использование 80% адресов в текущем, что может быть непросто, если нужен всего один /24 на ту вторую площадку. Тут, правда, упоминалось, что кроме второй площадки потом будет третья и т.д. и всюду по /24... так это, /20 состоит из 16-и /24х. :) -- Michael Уговорю вашего малыша покушать кашку. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 07:10:46PM +0300, Alexander Trotsai wrote:
AT> >>И будет так работать? А то как-то не доводилось такого строить. AT> >>Ведь, как будет вести себя маршрутизатор, видя два as-path к одной AS, но AT> >>разным prefix'ам? AT> > AT> >Будет маршрутизировать :) AT> > AT> >Только нужно будет создать в ripe-db соответствующий route object для AT> >каждого префикса. AT> > AT> >>А теперь приведу более реальный сценарий (который планируется): AT> >>/19 разбивается на два /20. Первый /20 анонситься от AS X. AT> >>Второй /20 разбивается на /24 и разъезжается по автономным площадкам и AT> >>анонситься каждый из этих блоков от AS X. AT> >>И так тоже будет работать? AT> >>И не раком ли это? Я что-то потерялся, как это будет уживаться в AT> > AT> >Лично с моей точки зрения - отнюдь не более раково, чем заводить AT> >для каждой такой площадки отдельный as-num. AT> > AT> >>маршрутизаторах + как это сделать правильно, относительно RIPE. AT> > AT> >RIPE обычно озвучивает свою позицию как "не увеличивать количество AT> >префиксов в fullview", и именно с этой позиции предлагает всем AT> >брать PA-адреса у непосредственного аплинка (т.к. в этом случае в мир AT> >идет один анонс /19 или больше). Т.к. в данном случае от увеличения AT> >количества анонсов все равно никуда не деться - RIPE скорее всего AT> >займет позицию "не увеличивать энтропию", т.е. не выдавать несколько AT> >as-num там, где можно обойтись одним. AT> > AT> AT> AT> А тут не обойтись... AT> AT> An Autonomous System (AS) is a group of IP networks run by one or more AT> network operators with a single, clearly defined routing policy. AT> AT> У него ж площадки абсолютно не связаные. И у каждой, насколько я понял, AT> будет именно свой clearly defined routing policy. AT> AT> Можно, конечно, AT> neighbor x.x.x.x allowas-in AT> но тогда одной из задач будет страхование от чужого криворучия. AT> AT> Я бы получал еще один ASN и разбивал PA. Против такого RIPE точно не будет AT> протестовать. Главное - честно глядя им в глаза, объяснить ситуацию. AT> Ну либо, если адресов мало или жадно - additional allocation. С PI - ну AT> его в баню. Под одну организацию не дадут. Тем более под LIR.
мне дали но это в чем-то подвиг :)
Мне тоже дали и даже без никаких проблем. Просто нужно объяснить, что из четырех ripe-324 goals в твоем случае Aggregation более веский аргумент чем Conservation... Предложил я им в качестве альтернативы /16 на /24x256 порезать. :D ;) -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi!
RIPE обычно озвучивает свою позицию как "не увеличивать количество префиксов в fullview", и именно с этой позиции предлагает всем брать PA-адреса у непосредственного аплинка (т.к. в этом случае в мир идет один анонс /19 или больше). Т.к. в данном случае от увеличения количества анонсов все равно никуда не деться - RIPE скорее всего займет позицию "не увеличивать энтропию", т.е. не выдавать несколько as-num там, где можно обойтись одним.
А тут не обойтись...
An Autonomous System (AS) is a group of IP networks run by one or more network operators with a single, clearly defined routing policy.
Согласен с предыдущими ораторами. Обоими. Т.е. классно было бы AS сэкономить, раз уж технически можно. Но по policy так делать не обязательно. P.S. Хм, еще раз убеждаюсь, что таки не все знают, что так может работать. -- Michael Встречаясь и прощаясь, не обольщаясь... =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Edward,
Т.е., инфраструктура AS X, под ней /20, а на другой площадке тоже будет AS X и другие /20. И при этом, они не связаны непосредственно между собой никак.
И будет так работать? А то как-то не доводилось такого строить. Ведь, как будет вести себя маршрутизатор, видя два as-path к одной AS, но разным prefix'ам?
А теперь приведу более реальный сценарий (который планируется):
/19 разбивается на два /20. Первый /20 анонситься от AS X. Второй /20 разбивается на /24 и разъезжается по автономным площадкам и анонситься каждый из этих блоков от AS X.
И так тоже будет работать?
Говорят, что большая фирма Level3 использует один и тот же AS в куче городов и стран. В смысле, может работать. -- Michael У тебя на своей планете ещё спички есть? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi! On Sun, Sep 11, 2005 at 12:20:26PM +0300, Andrey Elperin writes:
есть /19 под некой AS X. Планируется построить автономную площадку в другом городе, которая не будет связана с инфраструктурой AS X (никак). При этом, организация LIR и строит эту площадку для себя. Понимаю, что на эту площадку нужно получать AS, но, как быть с адресами? Заказывать и их или выкусывать из /19 (есть возможность разбить /19 на два /20). Что в этом случае говорит RIPE? Как сделать "не криво"?
AE> А почему бы в этом случае не анонсить половину /19 из другого AE> места из-под уже существующего as-num ? Разве маршрутизаторы принимают анонсы собственной AS извне? Мне кажется, получить на площадку собственный - AS менее кривое решение. А PI или PA - уже не так принципиально. -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 05:04:42PM +0300, Pavel Gulchouck wrote: PG> Hi! PG> On Sun, Sep 11, 2005 at 12:20:26PM +0300, Andrey Elperin writes: PG> >> есть /19 под некой AS X. Планируется построить автономную площадку в другом PG> >> городе, которая не будет связана с инфраструктурой AS X (никак). PG> >> При этом, организация LIR и строит эту площадку для себя. PG> >> Понимаю, что на эту площадку нужно получать AS, но, как быть с адресами? PG> >> Заказывать и их или выкусывать из /19 (есть возможность разбить /19 на два PG> >> /20). PG> >> Что в этом случае говорит RIPE? Как сделать "не криво"? PG> AE> А почему бы в этом случае не анонсить половину /19 из другого PG> AE> места из-под уже существующего as-num ? PG> Разве маршрутизаторы принимают анонсы собственной AS извне? принимают (если попросить) PG> Мне кажется, получить на площадку собственный - AS менее кривое решение. PG> А PI или PA - уже не так принципиально. по-моему это уже деланье из мухи такого, с хоботом принимать свою as конкретные префиксы -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Это вам не болты на микpосхемах кpутить =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 07:12:33PM +0300, Alexander Trotsai wrote:
PG> Разве маршрутизаторы принимают анонсы собственной AS извне?
принимают (если попросить) ^^^^^^^^^^^^^^ А как их попросить? Как-то особенно нужно отконфигурировать кошку?
PG> Мне кажется, получить на площадку собственный - AS менее кривое решение. [skip] принимать свою as конкретные префиксы
Фраза не совсем ясна. ps как я понял, работать по идее будет. А там будем по обстоятельствам смотреть. :) Всем спасибо! -- Edward Melnik. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 11, 2005 at 09:21:24PM +0300, Edward Melnik wrote: EM> On Sun, Sep 11, 2005 at 07:12:33PM +0300, Alexander Trotsai wrote: EM> > PG> Разве маршрутизаторы принимают анонсы собственной AS извне? EM> > EM> > принимают (если попросить) EM> ^^^^^^^^^^^^^^ EM> А как их попросить? EM> Как-то особенно нужно отконфигурировать кошку? писали ж - allowas-in EM> > PG> Мне кажется, получить на площадку собственный - AS менее кривое решение. EM> [skip] EM> > принимать свою as конкретные префиксы EM> Фраза не совсем ясна. от своей ас принимать только префиксы другой площадки остальное резать EM> ps как я понял, работать по идее будет. А там будем по EM> обстоятельствам смотреть. :) EM> Всем спасибо! EM> -- EM> Edward Melnik. EM> =================================================================== EM> uanog mailing list. EM> To Unsubscribe: send mail to majordomo@uanog.kiev.ua EM> with "unsubscribe uanog" in the body of the message -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc] Все пчёлы прилетели с мёдом, а одна - такая маленькая и вредная - с дёгтем =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (7)
-
Alexander Trotsai -
Andrey Elperin -
Anton Turygin -
Dmitry Kiselev -
Edward Melnik -
Michael Petuschak -
Pavel Gulchouck