ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[inet-admins] BGP communities 'n' more specific


  • To: <inet-admins@info.east.ru>
  • Subject: [inet-admins] BGP communities 'n' more specific
  • From: "Ilia Zubkov" <mur57@nichego.net>
  • Date: Mon, 2 Jul 2001 20:24:28 +0400
  • Delivered-To: inet-2317-ak@frog.east.ru
  • Delivered-To: inet-admins@info.east.ru



Вопрос по построению BGP:
Как правильно защищаться от more specific routes клиента, пришедших НЕ с
клиентского подключения?
(Например, от пира).

Поясняю задачу. Итак, дано:
    - клиент со своим AS плюс BGP сессия с ним на его подключении
    - его анонсы "маркируются" определенным внутренним коммьюнити
    - соответственно этому "маркеру" они анонсируются туда, куда нужно,  и
являются наиболее приоритетными
Однако routing на клента может быть "уведен", например, в сторону пира, если
от него прийдут more specific routes клиента.

Безусловно, можно на всех пирах, аплинках и иных клиентских сессиях
запретить принимать сети клиента через
filter-list/prefix-list/distribute-list, но как то такое решение не кажется
мне правильным. К тому же, в этом случае, во время временного падения сессии
клиент будет не доступен (или надо перестраивать все фильтры), хотя
теоретически он скорее всего имеет другое подключение к сети, раз уж имеет
свой AS.

Отсюда и вопрос: как наиболее правильно решить эту задачу.


Спасибо.

--
Sincerely yours,

Ilia Zubkov,
Educational Network technical director



=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.