Jump to content
Калькуляторы

RIPE DB и таблицы маршрутизации

Коллеги, а просветите меня в таком вопросе - есть ли связь между записями о маршрутизации в БД RIPE и реальными таблицами маршрутизации?

Например, в БД RIPE запись о привязке адресов к одной АС, а реально анонс приходит с другой.

Как поступают, к примеру, магистральные операторы в этом случае?

Есть ли механизм автоматической сверки таблиц в роутерах с БД RIPE?

Share this post


Link to post
Share on other sites

Как поступают, к примеру, магистральные операторы в этом случае?

Если от клиента - вероятно, отфильтруют. Если от аплинка - примут.

 

Есть ли механизм автоматической сверки таблиц в роутерах с БД RIPE?

Часто на клиентских линках прописываются as-sets, по которым строятся префикс-фильтры. Часто, но не всегда. Построение фильтров - от ручного до полного автомата. Есть еще RPKI validation, который уже вполне живой, но недостаточно широко используемый (origin validation).

 

Надо еще заметить, что RIPE DB - не единственный источник данных о префиксах. Есть еще 4 RIRs, и сторонние базы данных (PeeringDB, Merit's routing DB etc).

Share this post


Link to post
Share on other sites

Если от клиента - вероятно, отфильтруют. Если от аплинка - примут.

 

И что тогда делать новому владельцу адресов?

 

Надо еще заметить, что RIPE DB - не единственный источник данных о префиксах. Есть еще 4 RIRs

 

Да, я это понимаю.

 

и сторонние базы данных (PeeringDB, Merit's routing DB etc).

 

А вот про этих не знаю.

 

Есть еще RPKI validation, который уже вполне живой, но недостаточно широко используемый (origin validation).

 

Почитаю.

Спасибо за ликбез!

Share this post


Link to post
Share on other sites

Если от клиента - вероятно, отфильтруют. Если от аплинка - примут.

 

И что тогда делать новому владельцу адресов?

Править RIPE DB.

Share this post


Link to post
Share on other sites

Так я о той ситуации, когда в БД всё исправлено, а анонсы от старого владельца всё равно есть.

Писать/звонить в AS-origin, писать/звонить в AS-transit. IXPs обычно фильтры строгие применяют.

Share this post


Link to post
Share on other sites

Писать/звонить в AS-origin, писать/звонить в AS-transit. IXPs обычно фильтры строгие применяют.

 

Понятно. А у RIPE есть какие-то полномочия/рычаги повлиять на ситуацию?

Share this post


Link to post
Share on other sites

Понятно. А у RIPE есть какие-то полномочия/рычаги повлиять на ситуацию?

Такие же, как и у ARIN/APNIC/LACNIC/AFRINIC - т.е. никакие. Пиринг и интернет вообще - дела добровольные, а злостное косячество может и под статью подвести.

Share this post


Link to post
Share on other sites

Пиринг и интернет вообще - дела добровольные, а злостное косячество может и под статью подвести.

 

Так то оно так, но пойди попробуй засудить какого-нибудь засранца с условных Сейшельских островов.

Share this post


Link to post
Share on other sites

Коллеги, а просветите меня в таком вопросе - есть ли связь между записями о маршрутизации в БД RIPE и реальными таблицами маршрутизации?

Например, в БД RIPE запись о привязке адресов к одной АС, а реально анонс приходит с другой.

Как поступают, к примеру, магистральные операторы в этом случае?

Есть ли механизм автоматической сверки таблиц в роутерах с БД RIPE?

Добавлю что есть легитимный механизм анонсирования префикса принадлежащего одной AS от другой. Если аплинк строит фильтры по route-object то это решает проблему резервирования клиента на PA адресах. Вопрос с неправомерным анонсом решается через аплинков по цепочке.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.