что называется просто интересно, является ли такая ситуация нормальной whois3 -rB -T route 217.9.8.0/24 % This is the RIPE Whois query server #1. % The objects are in RPSL format. % % Note: the default output of the RIPE Whois server % is changed. Your tools may need to be adjusted. See % http://www.ripe.net/db/news/abuse-proposal-20050331.html % for more details. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html % Information related to '217.9.8.0/24AS15577' route: 217.9.8.0/24 descr: RDR-UA origin: AS15577 <--- AS15577 mnt-by: RDR-MNT changed: s.orlov@snt.ua 20050110 source: RIPE % Information related to '217.9.8.0/24AS34399' route: 217.9.8.0/24 descr: RDR-UA origin: AS34399 <--- AS34399 mnt-by: RDR-MNT changed: s.orlov@snt.ua 20050505 source: RIPE -- 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 4/27/06, Alexander Trotsai
что называется просто интересно, является ли такая ситуация нормальной
whois3 -rB -T route 217.9.8.0/24 % This is the RIPE Whois query server #1. % The objects are in RPSL format. % % Note: the default output of the RIPE Whois server % is changed. Your tools may need to be adjusted. See % http://www.ripe.net/db/news/abuse-proposal-20050331.html % for more details. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html
% Information related to '217.9.8.0/24AS15577'
route: 217.9.8.0/24 descr: RDR-UA origin: AS15577 <--- AS15577 mnt-by: RDR-MNT changed: s.orlov@snt.ua 20050110 source: RIPE
% Information related to '217.9.8.0/24AS34399'
route: 217.9.8.0/24 descr: RDR-UA origin: AS34399 <--- AS34399 mnt-by: RDR-MNT changed: s.orlov@snt.ua 20050505 source: RIPE
-- 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
-- /doka =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Vladimir,
Вообще-то, как на мой взгляд, не является
Почему? Просто любопытно.
что называется просто интересно, является ли такая ситуация нормальной
-- Michael Чем дальше в лес, тем злее дятлы. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет! On Thu, Apr 27, 2006 at 07:51:48AM +0300, Alexander Trotsai wrote:
что называется просто интересно, является ли такая ситуация нормальной
Да, совершенно нормальна. Более того, в некоторых регионах common practice использующаяся для организации multihoming и в тоже время экономии ASN2 space.
whois3 -rB -T route 217.9.8.0/24 % This is the RIPE Whois query server #1. % The objects are in RPSL format. % % Note: the default output of the RIPE Whois server % is changed. Your tools may need to be adjusted. See % http://www.ripe.net/db/news/abuse-proposal-20050331.html % for more details. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html
% Information related to '217.9.8.0/24AS15577'
route: 217.9.8.0/24 descr: RDR-UA origin: AS15577 <--- AS15577 mnt-by: RDR-MNT changed: s.orlov@snt.ua 20050110 source: RIPE
% Information related to '217.9.8.0/24AS34399'
route: 217.9.8.0/24 descr: RDR-UA origin: AS34399 <--- AS34399 mnt-by: RDR-MNT changed: s.orlov@snt.ua 20050505 source: RIPE
-- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
ну по логике, сеть не может одновременно находиться в двух автономных
системах :)
On 4/27/06, Michael Petuschak
Hi Vladimir,
Вообще-то, как на мой взгляд, не является
Почему?
Просто любопытно.
что называется просто интересно, является ли такая ситуация нормальной
-- Michael Чем дальше в лес, тем злее дятлы. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
-- /doka =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Vladimir,
ну по логике, сеть не может одновременно находиться в двух автономных системах :)
Хм, а почему бы не сделать multihoming без BGP у клиента? В смысле, что в этом не так? -- Michael Если ты не параноик, это не значит, что ОHИ за тобой не следят. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Dmitry,
Да, совершенно нормальна. Более того, в некоторых регионах common practice использующаяся для организации multihoming и в тоже время экономии ASN2 space.
А что такое ASN2 space? Опечатка? -- Michael =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет! On Thu, 27 Apr 2006, Vladimir Litovka wrote:
ну по логике, сеть не может одновременно находиться в двух автономных системах :)
"Находиться" != "заявляться из-под". Главное, чтобы эти 2 оригинирующие AS таки доставили трафик реальному потребителю. Потом ведь, вовсе необязательно эти анонсы будут в таблицах _одновременно_. RIPE DB / RADB описывает только _возможные_ пути анонсов. По четным дням, например, блок анонсирует AS15577, по нечетным - AS34399, все работает ;) Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 10:08:55AM +0200, Michael Petuschak wrote:
Да, совершенно нормальна. Более того, в некоторых регионах common practice использующаяся для организации multihoming и в тоже время экономии ASN2 space.
А что такое ASN2 space? Опечатка?
Двухбайтные автономные системы. Закончатся они похоже раньше чем IPv4. -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Привет! On Thu, Apr 27, 2006 at 11:10:30AM +0300, Dmitry Pryanishnikov wrote:
On Thu, 27 Apr 2006, Vladimir Litovka wrote:
ну по логике, сеть не может одновременно находиться в двух автономных системах :)
"Находиться" != "заявляться из-под". Главное, чтобы эти 2 оригинирующие AS таки доставили трафик реальному потребителю. Потом ведь, вовсе необязательно эти анонсы будут в таблицах _одновременно_. RIPE DB / RADB описывает только _возможные_ пути анонсов. По четным дням, например, блок анонсирует AS15577, по нечетным - AS34399, все работает ;)
Если мне мой склероз не изменяет BGP абсолютно до лампочки значение origin-as как на этапе приема маршрута (не мой ASN, значит гуд), так и на этапе best path selection (длина пути, но не конкретные значения). По-этому наличие в BGP двух анонсов одной и той же сети с разными origin-as и as-path ничему не противоречит. -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Да, согласен, про такой вариант я не подумал :) привык к тому, что
обычно есть своя AS :)
On 4/27/06, Michael Petuschak
Hi Vladimir,
ну по логике, сеть не может одновременно находиться в двух автономных системах :)
Хм, а почему бы не сделать multihoming без BGP у клиента? В смысле, что в этом не так?
-- Michael Если ты не параноик, это не значит, что ОHИ за тобой не следят. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
-- /doka =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 10:07:50AM +0200, Michael Petuschak wrote:
Hi Vladimir,
ну по логике, сеть не может одновременно находиться в двух автономных системах :)
Хм, а почему бы не сделать multihoming без BGP у клиента? В смысле, что в этом не так?
В multihoming без BGP - плохо то, что состояние каналов client-providerA и client-providerB не "мониторится". Сеть к клиенту заправляется обоими провайдерами статикой. Соответственно, при падении одного из каналов - часть траффика идет в /dev/null. То есть - какой-то EGP с клиентом таки нужен, а EGP у нас сейчас только один :) Да, можно поднять bgp выдав клиенту private-as, но это криво.... В орижинировании одной сети от двух AS плохо то, что фильтры сейчас строятся в основном посеточно. То есть - возможны ситуации, когда транзитный провайдер получит эту сеть с "неправильным" origin, и отдаст ее дальше. Да, это ошибка на уровне конфигурации нижестоящих провайдеров, но без возможности орижинирования сети от разных AS такого бы не было вообще... PS: пошел думать о том, что пора в добавление к prefix-фильтрам на каждого клиента вешать еще as-path filter.. :( =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Alexandre,
Хм, а почему бы не сделать multihoming без BGP у клиента? В смысле, что в этом не так?
В multihoming без BGP - плохо то, что состояние каналов client-providerA и client-providerB не "мониторится". Сеть к клиенту заправляется обоими провайдерами статикой. Соответственно, при падении одного из каналов - часть траффика идет в /dev/null. То есть - какой-то EGP с клиентом таки нужен, а EGP у нас сейчас только один :)
В общем, именно по поводу этого смайлика вопрос и назревал. Почему, собственно?
Да, можно поднять bgp выдав клиенту private-as, но это криво....
При наличии троих субъектов, видящих данный 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 Thu, Apr 27, 2006 at 02:55:17PM +0400, Alexandre Snarskii writes: AS> В орижинировании одной сети от двух AS плохо то, что фильтры сейчас AS> строятся в основном посеточно. То есть - возможны ситуации, когда AS> транзитный провайдер получит эту сеть с "неправильным" origin, AS> и отдаст ее дальше. Да, это ошибка на уровне конфигурации нижестоящих AS> провайдеров, но без возможности орижинирования сети от разных AS AS> такого бы не было вообще... Не очень понял. Скажем, есть возможные пути анонсов сетки: A-B-C или A-B-D. Провайдеру A все равно, кем ориджинирована сетка, она относится к блоку клиента B. А провайдер B должен эту сетку анонсить/шейпить/фильтровать/считать так или сяк, в зависимости от того, от кого он ее получил - фильтры ведь на C и D стоят разные, и community attrs ставятся тоже разные. Если ты имеешь ввиду, что провайдер A принимает от B as-set, состоящий только из B и C, но при этом все равно примет сеть по пути B-D, потому что она же входит в as-set B+C, то тут не вижу разницы со случаем, когда у клиента собственная автономка E, и пути анонсов менялись бы с A-B-C-E на A-B-D-E. AS> PS: пошел думать о том, что пора в добавление к prefix-фильтрам на AS> каждого клиента вешать еще as-path filter.. :( Ну это в принципе не вредно, но IMHO не является так уж необходимым, т.к. ты этим только защищаешь даунлинков от их ошибок, но добавляешь себе достаточно гемора. -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 01:19:55PM +0200, Michael Petuschak wrote:
Hi Alexandre,
Хм, а почему бы не сделать multihoming без BGP у клиента? В смысле, что в этом не так?
В multihoming без BGP - плохо то, что состояние каналов client-providerA и client-providerB не "мониторится". Сеть к клиенту заправляется обоими провайдерами статикой. Соответственно, при падении одного из каналов - часть траффика идет в /dev/null. То есть - какой-то EGP с клиентом таки нужен, а EGP у нас сейчас только один :)
В общем, именно по поводу этого смайлика вопрос и назревал. Почему, собственно?
Почему EGP один ? Потому что другого нет... не было надобности видимо, создавать еще один EGP :) BGP есть, всех устраивает. Кого не устраивает - дорабатывает в сторону mp-bgp, rfc2547, и прочего, но это остается BGP. Или я что-то пропустил, и таки появился еще один EGP ? Или почему с клиентом нужен именно EGP, а не IGP ? Вообще говоря, можно смириться с нарушением традиций и запустить протокол _внутреннего_ раутинга между _разными_ сетями, но это уж совсем криво. (на моей практике: bgp с выдачей клиенту private as - было, igp с клиентом - не было).
Да, можно поднять bgp выдав клиенту private-as, но это криво....
При наличии троих субъектов, видящих данный AS считать его приватным кажется мне неправильным.
О! Соответственно, для нормального multihoming нужен свой нормальный AS. И нормальный EGP (читай BGP) с аплинками/пирами. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Да, можно поднять bgp выдав клиенту private-as, но это криво....
При наличии троих субъектов, видящих данный AS считать его приватным кажется мне неправильным.
О! Соответственно, для нормального multihoming нужен свой нормальный AS. И нормальный EGP (читай BGP) с аплинками/пирами.
Кто спорит что со своим AS это более правильно. Только не стоит забывать про реалии. Бывает что запрашивая у RIPE /24 получаешь /25 и думаешь чего бы с этим сделать :( Т.е. схема с multihoming из под 2 разных AS тоже может работать, если абонент попросит ;) -- YY18-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 02:33:46PM +0300, Pavel Gulchouck wrote:
Hi!
On Thu, Apr 27, 2006 at 02:55:17PM +0400, Alexandre Snarskii writes: AS> В орижинировании одной сети от двух AS плохо то, что фильтры сейчас AS> строятся в основном посеточно. То есть - возможны ситуации, когда AS> транзитный провайдер получит эту сеть с "неправильным" origin, AS> и отдаст ее дальше. Да, это ошибка на уровне конфигурации нижестоящих ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AS> провайдеров, но без возможности орижинирования сети от разных AS ^^^^^^^^^^^ AS> такого бы не было вообще...
Не очень понял. Скажем, есть возможные пути анонсов сетки: A-B-C или A-B-D. Провайдеру A все равно, кем ориджинирована сетка, она относится к блоку клиента B. А провайдер B должен эту сетку анонсить/шейпить/фильтровать/считать так или сяк, в зависимости от того, от кого он ее получил - фильтры ведь на C и D стоят разные, и community attrs ставятся тоже разные.
Это если ставятся. Я подчеркнул в цитате, что да, анонс неправильного маршрута - это ошибка провайдера B. Но разбираться "как такое вообще стало возможным" придется network engineer'ам провайдера A, соответственно - их задача сделать так, чтобы анонсы, принимаемые ими от провайдера B были максимально корректными. Количество AS'ов растет, а количество грамотных network engineer'ов остается примерно одинаковым :( Нас буквально вчера очередной клиент пытался full-view накормить..
Если ты имеешь ввиду, что провайдер A принимает от B as-set, состоящий только из B и C, но при этом все равно примет сеть по пути B-D, потому что она же входит в as-set B+C, то тут не вижу разницы со случаем, когда у клиента собственная автономка E, и пути анонсов менялись бы с A-B-C-E на A-B-D-E.
AS> PS: пошел думать о том, что пора в добавление к prefix-фильтрам на AS> каждого клиента вешать еще as-path filter.. :(
Ну это в принципе не вредно, но IMHO не является так уж необходимым, т.к. ты этим только защищаешь даунлинков от их ошибок, но добавляешь себе достаточно гемора.
Не себе, а роботу ;) Он программный, ему что только prefix-list, что prefix-list + as-path менять, разница небольшая :) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Yury,
Бывает что запрашивая у RIPE /24 получаешь /25 и думаешь чего бы с этим сделать :(
А какие варианты? :) -- Michael Он в эхи заходил без приглашенья... =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi! On Thu, Apr 27, 2006 at 04:30:38PM +0400, Alexandre Snarskii writes:
То есть - какой-то EGP с клиентом таки нужен, а EGP у нас сейчас только один :)
В общем, именно по поводу этого смайлика вопрос и назревал. Почему, собственно?
AS> Почему EGP один ? Потому что другого нет... не было надобности видимо, AS> создавать еще один EGP :) BGP есть, всех устраивает. Кого не устраивает AS> - дорабатывает в сторону mp-bgp, rfc2547, и прочего, но это остается AS> BGP. Мне кажется, bgp постепенно перестает всех устраивать из-за времени релаксации. При падении канала до перехода на бэкап минут пять дауна в лучшем случае - IMHO это очень много. И это by design. Собственно, по умолчанию timeout 180 секунд - это куда при нынешних требованиях ip-телефонии и прочего? Ну и двухбайтовые as numbers, которые скоро закончатся. А после построения линка чихнуть боишься - любое изменение bgp policy (скажем, удлинение as-path) может привести к suppressed по пенальти - тоже, как по мне, не очень здоровая тема. Как-то IGP нынче развиваются намного более бурно, чем EGP. -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 15:47 +0300, Yury Yaroshevsky wrote:
Бывает что запрашивая у RIPE /24 получаешь /25 и думаешь чего бы с этим сделать :(
Сделать то, что RIPE сразу и предлагает - не брать /25 а переписать заявку на /24 ;) p.s. на lirportale есть шаблоны для PI (вместе с не менее замечательным калькулятором для расчета размера) -- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 Bike is the freedom of moving =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 03:56:27PM +0300, Pavel Gulchouck wrote:
Hi!
On Thu, Apr 27, 2006 at 04:30:38PM +0400, Alexandre Snarskii writes:
То есть - какой-то EGP с клиентом таки нужен, а EGP у нас сейчас только один :)
В общем, именно по поводу этого смайлика вопрос и назревал. Почему, собственно?
AS> Почему EGP один ? Потому что другого нет... не было надобности видимо, AS> создавать еще один EGP :) BGP есть, всех устраивает. Кого не устраивает AS> - дорабатывает в сторону mp-bgp, rfc2547, и прочего, но это остается AS> BGP.
Мне кажется, bgp постепенно перестает всех устраивать из-за времени релаксации. При падении канала до перехода на бэкап минут пять дауна в лучшем случае - IMHO это очень много. И это by design. Собственно, по умолчанию timeout 180 секунд - это куда при нынешних требованиях ip-телефонии и прочего? Ну и двухбайтовые as numbers, которые скоро закончатся. А после построения линка чихнуть боишься - любое изменение bgp policy (скажем, удлинение as-path) может привести к suppressed по пенальти - тоже, как по мне, не очень здоровая тема.
Как-то IGP нынче развиваются намного более бурно, чем EGP.
а) другого все равно нет :) б) используй нормальные раутеры, и все будет нормально. Наши раутеры почему-то переключаются в секунды... А если тебя и секунды не устраивают - use sonet/aps, mpls frr и/или bfd.. в) ну, то, что flap dampening concidered harmful - это уже довольно давно известно. В результате у нас на сети (и, как минимум, у одного из наших аплинков) оно выключено. г) то, что as'ы скоро кончатся - всем известно. Соответствующие меры предпринимаются как на уровне протокола http://www1.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-12.txt так и на уровне RIR'ов: http://www.ripe.net/ripe/policies/proposals/2005-12.html Ну и, повторюсь, другого все равно нет... =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 04:24:33PM +0300, Maxim Tuliuk wrote:
On Thu, Apr 27, 2006 at 15:47 +0300, Yury Yaroshevsky wrote:
Бывает что запрашивая у RIPE /24 получаешь /25 и думаешь чего бы с этим сделать :(
1. Сразу абонента послать на доработку заявки. 2. Взять денег и сделать все "под ключ". 1-е обычно переростает в фактическое обучение абонента и трату времению и может перетекать в 2-е ... Абонент же зачастую противится 2 варианту.
Сделать то, что RIPE сразу и предлагает - не брать /25 а переписать заявку на /24 ;)
BTW, а были прецеденты когда после получения сети /25 заявку переписывали и получали /24 ? Я о таких не слышал. Насколько это реально?
p.s. на lirportale есть шаблоны для PI (вместе с не менее замечательным калькулятором для расчета размера)
Когда я сам составляю заявку - я пишу ее как надо. :) Проблема возникает тогда - когда ее заполняет абонент. -- YY18-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 05:33:57PM +0400, Alexandre Snarskii writes:
On Thu, Apr 27, 2006 at 04:30:38PM +0400, Alexandre Snarskii writes:
То есть - какой-то EGP с клиентом таки нужен, а EGP у нас сейчас только один :)
В общем, именно по поводу этого смайлика вопрос и назревал. Почему, собственно?
AS>> Почему EGP один ? Потому что другого нет... не было надобности видимо, AS>> создавать еще один EGP :) BGP есть, всех устраивает. Кого не устраивает AS>> - дорабатывает в сторону mp-bgp, rfc2547, и прочего, но это остается AS>> BGP.
Мне кажется, bgp постепенно перестает всех устраивать из-за времени релаксации. При падении канала до перехода на бэкап минут пять дауна в лучшем случае - IMHO это очень много. И это by design. Собственно, по умолчанию timeout 180 секунд - это куда при нынешних требованиях ip-телефонии и прочего? Ну и двухбайтовые as numbers, которые скоро закончатся. А после построения линка чихнуть боишься - любое изменение bgp policy (скажем, удлинение as-path) может привести к suppressed по пенальти - тоже, как по мне, не очень здоровая тема.
Как-то IGP нынче развиваются намного более бурно, чем EGP.
AS> а) другого все равно нет :) AS> б) используй нормальные раутеры, и все будет нормально. Наши раутеры AS> почему-то переключаются в секунды... А если тебя и секунды не устраивают AS> - use sonet/aps, mpls frr и/или bfd.. Речь не о переключении собственных роутеров, а о времени распространения изменений в мире. AS> в) ну, то, что flap dampening concidered harmful - это уже довольно AS> давно известно. В результате у нас на сети (и, как минимум, у одного AS> из наших аплинков) оно выключено. В принципе, как механизм оно было бы полезно. Если б его как-то иначе реализовать. То есть, чтобы оно действительно защищало от частых флапов, но не мешало бы в нормальном случае, чтобы одно событие не вызывало большого пенальти из-за того, что оно распространяется по миру неравномерно. AS> г) то, что as'ы скоро кончатся - всем известно. Соответствующие AS> меры предпринимаются как на уровне протокола AS> http://www1.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-12.txt AS> так и на уровне RIR'ов: AS> http://www.ripe.net/ripe/policies/proposals/2005-12.html AS> Ну и, повторюсь, другого все равно нет... В том-то и дело, что все упирается в пункт а). -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Thu, Apr 27, 2006 at 15:56:27, gul wrote about "[uanog] Re: анонс":
Мне кажется, bgp постепенно перестает всех устраивать из-за времени релаксации. При падении канала до перехода на бэкап минут пять дауна в лучшем случае - IMHO это очень много. И это by design. Собственно, по умолчанию timeout 180 секунд - это куда при нынешних требованиях ip-телефонии и прочего? Ну и двухбайтовые as numbers, которые скоро закончатся. А после построения линка чихнуть боишься - любое изменение bgp policy (скажем, удлинение as-path) может привести к suppressed по пенальти - тоже, как по мне, не очень здоровая тема.
Как-то IGP нынче развиваются намного более бурно, чем EGP.
Размер as-number лечится экстенсивно. А вот другие проблемы - увы. И то что BGP это такой себе "RIP на стероидах", и проблемы с нормальной множественностью путей, и время схождения, и подпорки в виде weight/localpref возникшие не от хорошей жизни... И до 2^21 сетей только в стандартной схеме распределения IPv6, после чего дальняя аггрегация (которой нет) станет средством выживания... Осталось убедить Juniper & Cisco.:) -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 05:10:34PM +0300, Pavel Gulchouck wrote:
On Thu, Apr 27, 2006 at 05:33:57PM +0400, Alexandre Snarskii writes:
On Thu, Apr 27, 2006 at 04:30:38PM +0400, Alexandre Snarskii writes:
То есть - какой-то EGP с клиентом таки нужен, а EGP у нас сейчас только один :)
В общем, именно по поводу этого смайлика вопрос и назревал. Почему, собственно?
AS>> Почему EGP один ? Потому что другого нет... не было надобности видимо, AS>> создавать еще один EGP :) BGP есть, всех устраивает. Кого не устраивает AS>> - дорабатывает в сторону mp-bgp, rfc2547, и прочего, но это остается AS>> BGP.
Мне кажется, bgp постепенно перестает всех устраивать из-за времени релаксации. При падении канала до перехода на бэкап минут пять дауна в лучшем случае - IMHO это очень много. И это by design. Собственно, по умолчанию timeout 180 секунд - это куда при нынешних требованиях ip-телефонии и прочего? Ну и двухбайтовые as numbers, которые скоро закончатся. А после построения линка чихнуть боишься - любое изменение bgp policy (скажем, удлинение as-path) может привести к suppressed по пенальти - тоже, как по мне, не очень здоровая тема.
Как-то IGP нынче развиваются намного более бурно, чем EGP.
AS> а) другого все равно нет :)
AS> б) используй нормальные раутеры, и все будет нормально. Наши раутеры AS> почему-то переключаются в секунды... А если тебя и секунды не устраивают AS> - use sonet/aps, mpls frr и/или bfd..
Речь не о переключении собственных роутеров, а о времени распространения изменений в мире.
У нас два аплинка. К каждому из них мы подключены минимум в двух точках. В результате обрыв каждой из bgp-сессий приводит к изменениям только у нас и у аплинка. Сходимость все равно не моментальная, но - так как по миру ничего особо не распространяется, весьма быстрая.... С пирами все несколько хуже, но: и linx и ams-ix предоставляют по две сети пиринга, с многими мы пиримся и там и там и на обоих сетях (да, в результате - максимум четыре сессии. С другой стороны - обвал каждой из них нефатален и ведет только к "малому" пересчету). =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi Alexandre,
У нас два аплинка. К каждому из них мы подключены минимум в двух точках. В результате обрыв каждой из bgp-сессий приводит к изменениям только у нас и у аплинка. Сходимость все равно не моментальная, но - так как по миру ничего особо не распространяется, весьма быстрая....
С пирами все несколько хуже, но: и linx и ams-ix предоставляют по две сети пиринга, с многими мы пиримся и там и там и на обоих сетях (да, в результате - максимум четыре сессии. С другой стороны - обвал каждой из них нефатален и ведет только к "малому" пересчету).
Каждый клиент с PI должен иметь такую же схему подключения :) -- Michael А вот и утро, - очень кстати! =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi, В сообщении от Пятница, 28-Апр-2006 11:23 Michael Petuschak написал(a):
Hi Alexandre,
У нас два аплинка. К каждому из них мы подключены минимум в двух точках. В результате обрыв каждой из bgp-сессий приводит к изменениям только у нас и у аплинка. Сходимость все равно не моментальная, но - так как по миру ничего особо не распространяется, весьма быстрая....
С пирами все несколько хуже, но: и linx и ams-ix предоставляют по две сети пиринга, с многими мы пиримся и там и там и на обоих сетях (да, в результате - максимум четыре сессии. С другой стороны - обвал каждой из них нефатален и ведет только к "малому" пересчету).
Каждый клиент с PI должен иметь такую же схему подключения :)
Если интересует сходимость, смайлик нужно убрать. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Apr 27, 2006 at 16:57 +0300, Yury Yaroshevsky wrote:
Сделать то, что RIPE сразу и предлагает - не брать /25 а переписать заявку на /24 ;)
BTW, а были прецеденты когда после получения сети /25 заявку переписывали и получали /24 ? Я о таких не слышал. Насколько это реально?
Написать новую и указать что возвращаешь /25 ?
p.s. на lirportale есть шаблоны для PI (вместе с не менее замечательным калькулятором для расчета размера)
Когда я сам составляю заявку - я пишу ее как надо. :)
Проблема возникает тогда - когда ее заполняет абонент.
...но посылает то ее LIR и как никто должен быть заинтересован в том, чтобы заявка сразу была правильно написана -- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 Bike is the freedom of moving =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, Apr 28, 2006 at 10:23:19AM +0200, Michael Petuschak wrote:
Hi Alexandre,
У нас два аплинка. К каждому из них мы подключены минимум в двух точках. В результате обрыв каждой из bgp-сессий приводит к изменениям только у нас и у аплинка. Сходимость все равно не моментальная, но - так как по миру ничего особо не распространяется, весьма быстрая....
С пирами все несколько хуже, но: и linx и ams-ix предоставляют по две сети пиринга, с многими мы пиримся и там и там и на обоих сетях (да, в результате - максимум четыре сессии. С другой стороны - обвал каждой из них нефатален и ведет только к "малому" пересчету).
Каждый клиент с PI должен иметь такую же схему подключения :)
Я, вообще-то, писал лишь про то, что замена BGP на другой протокол не обязательна, и часть проблем (в частности, скорость сходимости) может быть решена без вмешательства во внутренности протокола, тем более без его замены :) А дальше - каждый выбирает для себя, стоит ли меньшее время сходимости дополнительных организационно/финансовых вложений.. Многие из наших клиентов считают, что оно того стоит. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (11)
-
Alexander Trotsai -
Alexandre Snarskii -
Alexey Balabushevich -
Dmitry Kiselev -
Dmitry Pryanishnikov -
Maxim Tuliuk -
Michael Petuschak -
Pavel Gulchouck -
Valentin Nechayev -
Vladimir Litovka -
Yury Yaroshevsky