+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Маршрутизаторы BGP с отражателями маршрутов, как правильно настроить??

Маршрутизаторы BGP с отражателями маршрутов, как правильно настроить??, RouterOS

jmatuska

Guest

25.02.2012 00:02:00

У кого-то есть хороший ресурс с инструкцией по правильной настройке BGP route reflectors на MikroTik OS? У нас планируется около 15 роутеров MikroTik RouterOS, между которыми будут установлены iBGP-сессии, и мы хотим, чтобы все наши полные интернет-маршруты из eBGP (от нескольких провайдеров) и внутренние iBGP-маршруты корректно распространялись по всей сети. В этой сети мы собираемся использовать только BGP для маршрутизации.

Сейчас мы сталкиваемся с проблемами — на последних нескольких роутерах появляются рекурсивные маршруты и петли маршрутизации для некоторых новых iBGP-анонсированных сетей. Вместо того чтобы месить полностью всю iBGP-сеть (что будет означать сотни пиров), я думал, что достаточно просто включить route reflection, но, как оказалось, это не так просто.

Изначально я думал, что нужно просто включить route reflect на каждом iBGP-пире и убедиться, что в каждом BGP-инстансе (по одному на роутер с нашим AS номером) включена опция client-to-client reflection. Но, судя по тому, что я читаю, нужно назначить только несколько роутеров route reflectors, а не все подряд, и я не совсем понимаю, как лучше это сделать.

Что вы думаете? Правильно ли я подхожу к этому, или стоит использовать другой протокол, например, OSPF для внутренних маршрутов, а затем перераспределять их в BGP на границе с провайдерами?

jmorby

Guest

05.08.2015 23:26:00

Ты получил когда-нибудь ответ на этот вопрос? 2 маршрутизатора с функцией Route Reflector, около 100 клиентов, включая 3-4 «пограничных» маршрутизатора, которые обмениваются BGP с вашими провайдерами (например). Конфигурируешь ли ты RR так, чтобы они общались друг с другом с route-reflect=yes или нет?

Также стоит уточнить, должны ли все клиенты находиться в одной подсети или они могут быть на нескольких прыжках (сегментах) друг от друга? В нашем случае мы используем OSPF для внутренних маршрутов и хотим, чтобы «клиенты» маршрутизировали трафик на основе разных BGP-параметров (MED, приоритет и так далее).

Jon

nz_monkey

Guest

06.08.2015 10:33:00

Это то же самое, что и на IOS и JunOS… Настройте все клиентские подключения на ваших RR так, чтобы они отражали маршруты. На сессиях между рефлекторами НЕ настраивайте отражение маршрутов. Также убедитесь, что у обоих RR установлен одинаковый cluster ID. Вот вам и кластерные Route Reflectors.

А чтобы ответить на ваш второй вопрос: да, клиенты могут находиться на нескольких прыжках от рефлектора. Для этого нужно использовать loopback-интерфейсы и OSPF для обеспечения доступности. Это довольно сложная тема, поэтому я бы советовал полностью разобраться в OSPF и BGP перед тем, как пытаться это реализовать, и протестировать свои знания в лабораторных условиях, прежде чем запускать в продакшен.

cesarvillalobos Guest	#4 0 04.12.2017 14:46:00 Привет, мои маршруты, изученные через RR, кажутся недоступными у пиров, почему так?

ZeroByte

Guest

04.12.2017 15:45:00

Скорее всего, IP-диапазоны подключений к Интернету на ваших граничных маршрутизаторах не анонсируются в вашем OSPF. iBGP не изменяет адрес следующего хопа при распространении префиксов. Например, если у вас есть граничный маршрутизатор, подключённый к провайдеру по каналу с адресацией 192.0.2.64/30, то этот диапазон должен быть доступен в вашем OSPF. Этот граничный маршрутизатор объявляет префиксы, полученные от ISP1, вашему route reflector (RR1) — следующий хоп для каждого такого префикса будет 192.0.2.65. Если какой-то другой BGP-маршрутизатор (R2) в вашей AS получает префикс 8.8.8.0/24 с адресом следующего хопа 192.0.2.65, тогда R2 должен выполнить рекурсивный поиск следующего хопа для 8.8.8.0/24, то есть определить, какой локальный следующий хоп лучше всего подходит для достижения 192.0.2.65. Какой бы адрес ни оказался подходящим, он и будет использоваться как фактический следующий хоп для 8.8.8.0/24 в таблице маршрутизации R2. Кратко: на граничных маршрутизаторах обязательно добавьте network=x.x.x.x/30 для каждого интерфейса, выходящего в ISP, и сделайте эти интерфейсы пассивными в OSPF, чтобы iBGP-соседи знали, как добираться до провайдера. Ещё одной возможной причиной может быть то, что если вы меняли конфигурацию области/целевой области по умолчанию на маршрутизаторах, то случайно могли нарушить рекурсивные поиски, но это вряд ли.

sri2007 Guest	#6 0 10.01.2018 16:56:00 Необходимо настроить оба Route-reflector на один и тот же идентификатор кластера.

JimmyNyholm

Guest

11.01.2018 07:27:00

Другие уже дали ответы на твой вопрос. У меня только ещё один момент. Когда используешь MT в качестве route reflector и следуешь инструкциям, что рефлектор на самом деле не участвует в передачи данных, MT будет отражать только установленные маршруты; он не может быть чистым рефлектором без обновления FIB (если только его не попросили об этом).

airbanduk Guest	#8 0 11.01.2018 13:32:00 Или установите следующий переход, чтобы принудительно направлять себя к RR на клиентах, если вы не хотите рекламировать внешние сети в вашем домене OSPF.

airbanduk

Guest

11.01.2018 13:49:00

Это не обязательное условие, и на самом деле может привести к потере трафика, если к этому не подойти с умом. Если не все клиенты полностью связаны с обоими route reflectors или возникают множественные сбои каналов, route reflectors могут не пересылать информацию о маршрутах своим подключённым пирами из-за одинаковых cluster ID. В некоторых топологиях выставлять одинаковый cluster ID на обоих route reflectors — плохая идея.

sri2007

Guest

#10

12.01.2018 20:01:00

На самом деле, согласно RFC 4456 (https://tools.ietf.org/html/rfc4456), это обязательно, даже когда настраиваешь большую сеть с несколькими RR — тогда можно добавлять разные Cluster-ID. Одна из лучших практик — именно то, что ты сказал: каждый роутер должен быть настроен как клиент-рефлектор маршрутов для обоих route-reflectors, в этом и смысл установки двух RR. Однако мне интересно, в каких топологиях резервные route-reflectors с одинаковым cluster-id могут вызвать проблемы?

airbanduk

Guest

#11

14.01.2018 15:57:00

Можешь, пожалуйста, указать часть в RFC, где сказано, что нужно использовать один и тот же ID на всех участниках одного кластера? Я хотел нарисовать схему ситуации, которая приведёт к blackholing, но нашёл такую на этом сайте http://network-101.blogspot.co.uk/2011/06/bgp-cluster-id-loop-prevention.html. Когда cluster ID совпадают, R2 не узнаёт префиксы от R4. Как только cluster ID разные — все префиксы узнаются всеми маршрутизаторами. Конечно, это лабораторка, но всякий раз, когда у вас нет полной связности между обоими RR и каждым клиентом, есть риск потерять маршруты при одинаковых cluster ID. Я всё ещё не могу придумать ситуацию, где нужно использовать одинаковый cluster ID на RR. Может, ты подскажешь?

ZeroByte

Guest

#12

15.01.2018 16:17:00

Я бы настороженно относился к любому, кто выкладывает статьи по BGP и при этом использует IP-адреса линков для iBGP-сессий, ведь всем давно известно, что для iBGP лучше использовать loopback-адреса. Возможно, автор просто ленился и сделал быстрый лабораторный пример "на коленке", но настроить loopback-адреса в GNS3 — это пара секунд, если ты хотя бы немного занимаешься лабораторными заданиями. С другой стороны, я сам не особо разбирался с RR и cluster ID, так что мне интересно, что скажет sri2007 по этому поводу.

airbanduk

Guest

#13

15.01.2018 21:10:00

Действительно, но я думаю, что тут речь не столько о «как сделать», сколько о примере того, как работают cluster ID. Главное — это не просто ставить одинаковый cluster ID на всех route reflector в кластере каждый раз, когда включаешь рефлексию. Нужно обдумать, действительно ли это нужно, а не делать только потому, что кто-то сказал «так надо». Единственный сценарий, который я могу представить, когда одинаковый cluster ID действительно нужен — это большая сеть с несколькими кластерами, где при передаче обновлений из кластера в кластер меняются некоторые параметры, например next-hop. В таком случае важно, чтобы каждый кластер получил обновление только один раз. В этой статье на PacketPushers есть отличный раздел, где подробно рассказано о двух способах настройки: http://packetpushers.net/bgp-rr-design-part-1/

sri2007

Guest

#14

16.01.2018 14:53:00

Привет!! Вчера был загруженный понедельник… В RFC явно сказано следующее: «Обычно у группы клиентов есть один RR. В таком случае кластер идентифицируется по BGP Identifier этого RR. Однако это создает единую точку отказа, поэтому, чтобы можно было использовать несколько RR в одном кластере, все RR в кластере могут быть настроены с 4-байтным CLUSTER_ID, чтобы RR мог отбрасывать маршруты от других RR внутри одного кластера.»

Так что каждый может понять это как рекомендацию, но я понял твою мысль: когда у роутера только одно подключение (просто чтобы объяснить топологию) к одному RR, в этом случае действительно плохая идея ставить один и тот же Cluster ID из-за поведения BGP при одинаковом Cluster-ID в префиксе.

Но, на мой взгляд, этот пример — плохая практика и смысла в нем нет, потому что идея иметь двух RR — увеличить время безотказной работы иBGP решения, так зачем же настраивать Route-Reflect клиент только на одном RR, если можно подключить к обоим?

Я создавал множество сценариев с двумя RR и разным количеством роутеров (от 4 до сотен), так что каждый роутер может установить iBGP-сессию с обоими Route-Reflector, и тогда легко получается топология с высокой доступностью.

ZeroByte

Guest

#15

16.01.2018 16:09:00

Думаю, здесь ключевой момент касается именно этого примера. RRs должны игнорировать префиксы друг друга при кластеризации, потому что предполагается, что все клиенты RR обмениваются маршрутами с обоими RR. Для меня это логично. Кроме того, я в целом скептически отношусь к решениям с «next hop self», ведь весь смысл iBGP в том, чтобы не менять next hop, чтобы клиент мог использовать IGP (OSPF/EIGRP/IS-IS и т.д.) для поиска самого оптимального следующего хопа к объявленному шлюзу для любого префикса. При этом расстояния в IGP могут даже влиять на выбор действительно лучшего маршрута.

airbanduk

Guest

#16

16.01.2018 21:00:00

Но в RFC не сказано, что нужно использовать один и тот же cluster ID на всех route reflector в кластере, и в этом мой аргумент. Единственный минус, который я вижу в том, чтобы не использовать один и тот же cluster ID — это то, что вы получите две копии каждого обновления, а это тратит чуть больше памяти и ресурсов процессора. Если бы это была вся глобальная таблица, возможно, я бы задумался о необходимых ресурсах для обработки, но для ~2000 префиксов меня это не беспокоит. Используя разные cluster ID (или просто не задавая их, и они по умолчанию равны router_id) в одном кластере, у вас всё равно будет высокая доступность, полная информация о маршрутах и защита от нескольких (хотя и маловероятных) отказов каналов, которые могли бы привести к потере трафика. Я бы предпочёл знать, зачем я включаю или отключаю ту или иную функцию, а не делать это просто потому, что кто-то сказал так надо. Просто мне любопытно. И хотя все мы любим повторять, что есть лучшие практики (я сам так делаю), не каждая топология — это идеально спроектированная сеть с избыточностью и высокой устойчивостью. Иногда приходится делать лучшее из того, что есть, и именно поэтому существует несколько способов достичь одной и той же цели — гибкость в развертывании очень важна.

jtommasi Guest	#17 0 16.09.2014 18:22:00 Как настраивать iBGP-пиры, если мы хотим иметь два Route Reflector’а для отказоустойчивости? Нужно ли настраивать пиринг между RR? Если да, то нужно ли включать «route-reflect» именно на этом пиринге между ними?

AlexS Guest	#18 0 17.09.2014 05:09:00 Глупый вопрос: почему бы не использовать OSPF для внутренней маршрутизации?

jtommasi Guest	#19 0 17.09.2014 19:25:00 Потому что я использую BGP для MPLS IP VPN. Также я использую OSPF для маршрутов магистрали.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры