The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Покритикуйте конфиг для quagga\bgpd, !*! sed, 20-Апр-08, 14:23  [смотреть все]
что имеем:
два маршрутизатора с quagga+bgpd, находящиеся в разных местах(за каждым из них своя внутренняя подсеть). Между ними есть линк, но ненадежный. К каждому маршрутизтору есть линк от вышестоящих провайдеров. От каждого провайдера предполагается получать fullview. Естественно есть своя AS и PI.

что хочу получить:
При падении одного прова, чтоб трафик шел через соседний наш маршрутизатор(и подключенного к нему прова). Если падает линк между нашими маршрутизаторами, то каждый маршрутизатор пользовал линк от провайдера, к которому он подключен напрямую. Ну и возможность рализовать балансировку нагрузки в будущем между разными провайдерами.

Какие есть идеи:
Устанавливаем iBGP между нашими маршрутизаторами. Разделяем пул PI адресов попалам. На каждом маршрутизаторе напрямую провайдерам анонсируем только одну половину PI. Вторую половину пула PI каждый маршрутизатор получает от соседа (еслди с линком всё впорядке) и также анонсирует провайдеру к которому он напрямую подключен. Запрещаем передавать апдейты между провайдерскими AS чтобы через нас не пошел транзитный трафик. Точнее разрешаем к провайдерам апдейты, которые анонсирует изменения только в нашей AS, остальные - запрещаем.

Какие конфиги получились (IP и номера AS вымышленные):

Маршрутизатор 1

Current configuration:
!
hostname rw-bgpd-1
password pass
enable password pass
!
router bgp 12345 #наша AS
bgp router-id 1.1.1.1
network 1.1.1.0/25 #кусок анонсируемого пула PI
neighbor 1.1.1.129 remote-as 12345 #наш соседний маршрутизатор
neighbor 33.33.33.33 remote-as 20485 #маршрутизатор провайдера
neighbor 33.33.33.33 route-map denyforegin out #запрещаем передавать апдейты между провайдерами
!
route-map denyforegin permit 10 #разрешаем все апдейты касающиеся только нашей AS остальное запрещаем
match as-path 12345
!
line vty
!
end


Маршрутизатор 2

Current configuration:
!
hostname rw-bgpd-2
password pass
enable password pass
!
router bgp 12345 #наша AS
bgp router-id 1.1.1.129
network 1.1.1.128/25 #кусок анонсируемого пула PI
neighbor 1.1.1.1 remote-as 12345 #наш соседний маршрутизатор
neighbor 44.44.44.44 remote-as 44544 #маршрутизатор провайдера
neighbor 44.44.44.44 route-map denyforegin out #запрещаем передавать апдейты между провайдерами
!
route-map denyforegin permit 10 #разрешаем все апдейты касающиеся только нашей AS остальное запрещаем
match as-path 12345
!
line vty
!
end


Вопрос,
1) будет ли всё это работать как задумано?
2) Правильно ли написан route-map разрешающий апдейты касающиеся только нашей AS, остальное запрещающей?
3) Будет передваваться анонс второй половины PI от нашего соседнего маршрутизатора или его надо как-то разрешить явно?

  • Покритикуйте конфиг для quagga\bgpd, !*! sed, 12:20 , 21-Апр-08 (1)
    хм, может всё таки, кто из старших товарисчей наставит на путь истинный ? :]
  • Покритикуйте конфиг для quagga\bgpd, !*! cant, 21:56 , 22-Апр-08 (2)
    >что имеем:
    >два маршрутизатора с quagga+bgpd, находящиеся в разных местах(за каждым из них своя
    >внутренняя подсеть). Между ними есть линк, но ненадежный. . .
    > . . .
    > Если падает линк между нашими маршрутизаторами, то каждый
    >маршрутизатор пользовал линк от провайдера, к которому он подключен напрямую. Ну
    >и возможность рализовать балансировку нагрузки в будущем между разными провайдерами.
    >

    вот это плохо что ненадежный ...
    вот если сломается, что quagga подумает, когда к неё по eBGP придет префикс с ориджином своей же AS ?   да и какой нормальный апстрим в сторону вашей же AS такой анонс пропустит.
      Вот такие грабли вижу.  

    • Покритикуйте конфиг для quagga\bgpd, !*! sed, 10:31 , 23-Апр-08 (3)
      ну то что ненадежный хуже надежного, это понятно, но чем богаты ... это есть как данность и соответственно надо извлечь из этого максимум пользы... :[

      Маршрутизация в BGP основана на анонисруемых подсетках или все же номерах AS? Что-то вы посеяли во мне смутные сомнения.

      Насчет получения собственного номера AS через eBGP- вопрос интересный, как я понимаю между подсетями нашей AS в этом случае через eBGP трафик не пойдет, но в данном случае главная задача - обеспечить выход в инет из внутренних подсетеей через оба маршрутизатора, даже при падении линка между ними. В таком варианте предложеный вариант будет работать?

      Также больше интересуе момент как не выпустить префиксы получаемые от одного провайдера - другому, чтоб не получить транзитный трафик через свою подсеть.

      С bgp знаком только в теории, а сейчас пришло время практики, очень не хочется сильно накосячить при запуске всего это механизма в действие, поэтому и терзаю гуру своими глупыми вопросами, спасибо за помощь :]

      • Покритикуйте конфиг для quagga\bgpd, !*! cant, 12:18 , 23-Апр-08 (4)
        >
        >Маршрутизация в BGP основана на анонисруемых подсетках или все же номерах AS?
        >Что-то вы посеяли во мне смутные сомнения.
        >

        На "подсетках" в первую очередь.


        >Насчет получения собственного номера AS через eBGP- вопрос интересный, как я понимаю
        >между подсетями нашей AS в этом случае через eBGP трафик не
        >пойдет, но в данном случае главная задача - обеспечить выход в
        >инет из внутренних подсетеей через оба маршрутизатора, даже при падении линка
        >между ними. В таком варианте предложеный вариант будет работать?
        >

        Такой вариант должен работать, если будете выплевывать трафик наружу по дефолту, а он там у апстримов найдет правильную дорогу.


        >Также больше интересуе момент как не выпустить префиксы получаемые от одного провайдера
        >- другому, чтоб не получить транзитный трафик через свою подсеть.
        >

        ну это дело техники . . . если апстримы знакомы с bgp лучше Вас, то они сами не допустят этого.

        • Покритикуйте конфиг для quagga\bgpd, !*! sed, 14:59 , 23-Апр-08 (5)
          >Такой вариант должен работать, если будете выплевывать трафик наружу по дефолту, а
          >он там у апстримов найдет правильную дорогу.

          хм, а при получении fullview в чем будет проблема? Как я понимаю все маршруты проходящие через наш соседний маршрутизатор (из нашей AS) отмирают при падении линка между ними и фактически остаётся только то что анонсирует провайдер непосредственно подключенный к данному маршрутизатору или в чем-то ещё есть подвох?

          >ну это дело техники . . . если апстримы знакомы с bgp
          >лучше Вас, то они сами не допустят этого.

          Да вот кто их знает... может не порубят, лучше уж сразу сделать это у себя, чтоб быть спокойным и однажды не получить транзит через свою AS. Так вариант с "match as-path" будет правильным решением для этого?

          • Покритикуйте конфиг для quagga\bgpd, !*! cant, 19:20 , 23-Апр-08 (6)
            >[оверквотинг удален]
            >>>
            >>Такой вариант должен работать, если будете выплевывать трафик наружу по дефолту, а
            >>он там у апстримов найдет правильную дорогу.
            >
            >хм, а при получении fullview в чем будет проблема? Как я понимаю
            >все маршруты проходящие через наш соседний маршрутизатор (из нашей AS) отмирают
            >при падении линка между ними и фактически остаётся только то что
            >анонсирует провайдер непосредственно подключенный к данному маршрутизатору или в чем-то ещё
            >есть подвох?
            >

            Виноват, конечно, все так. Такой вариант должен работать.

            Если связность между офисами не нужна, то и дефолты особо не нужны, при наличии fullview.

            >
            >... чтоб быть спокойным и однажды не получить транзит
            >через свою AS. Так вариант с "match as-path" будет правильным решением
            >для этого?

            Анонсируйте только свои префиксы и дело с концом, для этого смотреть в as-path вроде некчему.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру