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

Маршруты BGP не распространяются между iBGP и eBGP

Маршруты BGP не распространяются между iBGP и eBGP, RouterOS

dfroe

Guest

08.03.2014 21:34:00

Я заменяю предыдущую P2P-связь на базе OpenWRT двумя устройствами RB912. Пока что беспроводная часть работает отлично: хороший сигнал и производительность. Но у меня проблемы с конфигурацией BGP. Оба сайта образуют свои AS (сайт A — AS 64600, сайт B — AS 64601). Каждый сайт имеет магистраль с несколькими роутерами. В магистрали используется OSPF и iBGP. Два роутера в магистрали выступают в роли iBGP route reflectors. ether1 на MikroTik подключен к магистрали. OSPF работает корректно, все внутренние сети доступны. Также мне удалось успешно настроить iBGP-пиринги с двумя route reflectors. Между двумя MikroTik устройствами установлено eBGP пиринг через wlan1. Чтобы было проще понять, я визуализировал важную часть сети на приложенной схеме. Я сосредоточусь на AS 64601 (хотя для AS 64600 ситуация аналогична).

Пока пиринги работают. RB также узнаёт все маршруты от iBGP. Но эти маршруты не распространяются по моему eBGP пирингу к другому RB. На данный момент фильтры на RB не используются.

Вот моя конфигурация BGP:
[admin@BaseBox5-CPE] > /routing bgp export
mar/08/2014 22:04:24 by RouterOS 6.10
/routing bgp instance set default as=64601 router-id=172.24.8.2
/routing bgp peer add name=basebox5-ap nexthop-choice=force-self remote-address=172.24.3.33 remote-as=64600 tcp-md5-key=XXX ttl=1 update-source=wlan1
add name=fortigate nexthop-choice=force-self remote-address=172.24.8.4 remote-as=64601 ttl=1 update-source=ether1
add name=cisco nexthop-choice=force-self remote-address=172.24.8.3 remote-as=64601 ttl=1 update-source=ether1

Статус BGP показывает, что префиксы получены от iBGP пиров:
[admin@BaseBox5-CPE] > /routing bgp peer print status
Flags: X - отключён, E - установлено
0 E name=“basebox5-ap” instance=default remote-address=172.24.3.33 remote-as=64600 tcp-md5-key=“XXX” nexthop-choice=force-self hold-time=3m ttl=1 update-source=wlan1 state=established uptime=22m36s prefix-count=1 updates-received=1 updates-sent=0
1 E name=“fortigate” instance=default remote-address=172.24.8.4 remote-as=64601 nexthop-choice=force-self hold-time=3m ttl=1 update-source=ether1 state=established uptime=24m22s prefix-count=18 updates-received=18 updates-sent=0
2 E name=“cisco” instance=default remote-address=172.24.8.3 remote-as=64601 nexthop-choice=force-self hold-time=3m ttl=1 update-source=ether1 state=established uptime=18m35s prefix-count=17 updates-received=17 updates-sent=0

И вот самая интересная (и сбивающая с толку) часть — ни один маршрут не рекламируется этим RB. Я ожидал, что RB объявит маршруты, полученные от iBGP, своему eBGP пиру.

[admin@BaseBox5-CPE] > /routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF

Кроме того, подтверждая это, я не получаю никаких префиксов на другом RB.

[admin@BaseBox5-AP] > /routing bgp peer print status where name=“BaseBox5-CPE”
Flags: X - отключён, E - установлено
5 E name=“BaseBox5-CPE” instance=default remote-address=172.24.3.34 remote-as=64601 tcp-md5-key=“XXX” nexthop-choice=force-self hold-time=1m30s ttl=1 update-source=wlan1 state=established uptime=47m26s prefix-count=0 updates-sent=1 updates-received=0

Есть ли что-то особенное, что нужно настроить, чтобы маршруты BGP передавались/распространялись на другие eBGP пиры? Ранее, с устройством на OpenWRT (с Quagga в качестве роутингового демона) это работало как положено.

Заранее спасибо за любые советы!

johnvam Guest	#2 0 15.10.2014 09:39:00 Наконец-то, можно ли перераспределять маршруты BGP между двумя одинаковыми AS?

faisali

Guest

20.10.2014 13:27:00

Мы так делаем сегодня в нашей сети. У нас есть два Edge-маршрутизатора, которые обмениваются eBGP с разными внешними пирами, а между этими двумя Edge-маршрутизаторами работают iBGP и OSPF. Пару советов и рекомендаций.

В нашем случае мы хотим иметь полную таблицу маршрутов на обоих iBGP-пирах, поэтому у нас включена настройка route-reflection. Это настроено в двух местах: во-первых, “Client-to-Client” рефлексия под настройками по умолчанию для BGP-инстанса, во-вторых — “Route-Reflector” в настройках BGP Peer Instance.

Мы передаём маршруты в eBGP через фильтры. Причём не только наши маршруты, но и маршруты для downstream BGP клиентов. Вот фрагмент того, как это настроено:

/routing bgp peer print
name="GTT-Tinet" instance=default remote-address=199.229.229.25 remote-as=3257
tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=default in-filter=tinet-mia-in out-filter=tinet-mia-out address-families=ip
default-originate=never remove-private-as=no as-override=no passive=no use-bfd=no

Routing Filter выглядит так:

/routing bgp peer print
0 chain=tinet-mia-out match-chain=our-cidr invert-match=no action=accept
set-bgp-prepend-path="" append-bgp-communities=65003:3356

1 chain=tinet-mia-out match-chain=SDF-11280 invert-match=no action=accept
set-bgp-prepend-path="" append-bgp-communities=65003:3356

2 chain=tinet-mia-out match-chain=SDG-10302 bgp-communities=11280:115 invert-match=no
action=accept set-bgp-prepend-path="" append-bgp-communities=65003:3356

3 chain=tinet-mia-out match-chain=TNN-46215 bgp-communities=11280:115 invert-match=no
action=accept set-bgp-prepend-path=""

4 X chain=tinet-mia-out match-chain=CF-6598 bgp-communities=11280:115 invert-match=no
action=accept set-bgp-prepend-path=""

5 chain=tinet-mia-out match-chain=DIE-40875 bgp-communities=11280:115 invert-match=no
action=accept set-bgp-prepend-path=""

6 X chain=tinet-mia-out match-chain=CF-29846 bgp-communities=11280:115 invert-match=no
action=accept set-bgp-prepend-path=""

7 X chain=tinet-mia-out match-chain=HQD-40784 invert-match=no action=accept
set-bgp-prepend-path=""

8 X chain=tinet-mia-out bgp-communities=11280:115 invert-match=no action=accept
set-bgp-prepend-path=""

9 chain=tinet-mia-out match-chain=OPT-29866 invert-match=no action=accept
set-bgp-prepend-path=""

10 chain=tinet-mia-out invert-match=no action=discard set-bgp-prepend-path=""

А вот как выглядит один из этих фильтров, например, chain=SDG-10302:

/routing filter print where chain=SDG-10302
Flags: X - отключено
0 chain=SDG-10302 prefix=69.55.160.0/20 prefix-length=20-24 invert-match=no action=accept
set-bgp-prepend-path=""

dfroe

Guest

03.01.2015 12:52:00

Тем временем я попытался разобраться, почему RouterOS не правильно распространяет BGP-маршруты в моём сценарии. Оказалось, что это некое «особое» поведение реализации BGP в RouterOS. Обычно ожидается, что все маршруты, которые были получены через BGP, будут передаваться всем другим BGP-пирами (если нет фильтров, петель и т.п.). Другими словами, всё, что находится в вашей BGP базе/таблице, должно быть распространено дальше. Но стек BGP в RouterOS делает ещё одну проверку при пересылке BGP-маршрутов: для каждого маршрута, который нужно передать через BGP, он проверяет, действительно ли этот маршрут активен в обычной таблице маршрутизации. В моём сценарии я использую OSPF с более низкими административными расстояниями, чтобы контролировать поток трафика внутри каждого AS, а BGP — для распространения маршрутов между AS. Это значит, что в таблице маршрутизации ROS (fdb) OSPF-маршрут перекрывает BGP-маршрут — именно так и задумано. Но поскольку теперь активным в таблице маршрутизации является OSPF-маршрут, а не BGP, то BGP-маршрут тоже не будет распространяться другим BGP-пирам (проверка активности BGP-маршрута не пройдена). Конечно, многое зависит от архитектуры вашей сети, но в моём случае это делает одновременную работу нескольких протоколов маршрутизации, таких как BGP и OSPF, на устройстве с RouterOS практически невозможной. У других производителей (Cisco, Fortinet, Juniper, Extreme и программных демонов типа Quagga) я привык, что на одних устройствах может работать несколько протоколов. И управлять трафиком внутри AS с помощью OSPF, а для распространения маршрутов между AS использовать BGP — для меня было привычным решением. В итоге я обнаружил, что у Juniper JunOS тоже есть похожая фича в BGP. Они тоже проверяют, активен ли BGP-маршрут в таблице маршрутизации, когда передают его другим BGP-пирам (в то время как Cisco и Fortinet, насколько я знаю, таких проверок не делают). Но — и это приятный момент — в JunOS есть настраиваемая опция «advertise-inactive», с помощью которой можно включать или отключать эту дополнительную проверку. В итоге несколько месяцев назад я обсудил это с поддержкой MikroTik. Вот что я написал по сути проблемы: Поддержка MikroTik сообщила, что изменить поведение нынешнего BGP-стека версии 6 нельзя. Но они разрабатывают новую реализацию BGP для версии 7, где «могут легко добавить эту функцию». Так что остаётся надеяться, что в v7 реализация BGP будет гораздо лучше и решит некоторые проблемы и ограничения, с которыми мы сталкиваемся сейчас.

jkarras

Guest

03.01.2015 14:35:00

Как же проверка, о которой ты говоришь, не является просто предотвращением петель, которое выполняет iBGP? То есть iBGP объявляет только маршруты, которые возникли локально, поэтому нужен полный меш или route-reflector.

dfroe Guest	#6 0 03.01.2015 15:23:00 Хороший вопрос — на который, скорее всего, сможет ответить только тот, кто писал реализацию BGP в ROS. Полностью с вами согласен, что не должно быть никаких «автоматических скрытых фильтров». Никто о них практически не знает (я не встречал, чтобы эта функция — фильтрация неактивных маршрутов — была где-то задокументирована), они порой трудно понимаются, всегда есть риск что-то сломать, а ещё хуже, когда их нельзя отключить. Моё предположение — пытались добавить какие-то дополнительные проверки, чтобы убедиться, что весь трафик реально форвардится так же, как его распространяет протокол маршрутизации. В ситуации, когда у вас одновременно iBGP, eBGP и OSPF, трафик для BGP-маршрута может идти по OSPF (если OSPF «перебивает» BGP в таблице маршрутизации). Но это нормально — и в моём случае как раз именно этого я и хочу. Мой сценарий такой: у меня внутри AS работают OSPF и iBGP, а снаружи — eBGP с другими AS. iBGP используется для передачи BGP-маршрутов с одного конца моего AS на другой ← eBGP — [R1] ← iBGP → [R2] — eBGP → . Внутри моего AS (то есть между R1 и R2) я также намеренно использую OSPF, чтобы влиять на процесс маршрутизации. В моём случае мне нужно, чтобы трафик, по возможности, проходил через выделенный файрвол. Для этого файрвол перераспределяет BGP-маршруты в OSPF, при этом файрвол становится next-hop. Так что R1 и R2 сохраняют BGP-соединения для обмена маршрутами, но когда файрвол онлайн, они «перенаправляют» трафик через него — потому что у OSPF лучший метрика, и маршруты через файрвол становятся активными в таблице маршрутизации. Это очень удобно, потому что позволяет заставить трафик идти через файрвол, оставляя обычный путь в резерве. Но затем R2 перестаёт распространять BGP-маршруты от R1 — они фильтруются этой скрытой функцией «фильтр неактивных маршрутов». Если бы у меня был выбор, я бы очень хотел видеть опцию advertise-inactive, как в JunOS. То есть, существующий сейчас в ROS код «фильтрации неактивных маршрутов» должен быть обёрнут в условие if, чтобы можно было пропускать эти проверки при необходимости. В целом стек BGP в ROS не так уж плох, но есть некоторые нюансы, которые могут стать настоящими камнями преткновения. Надеюсь, эта информация поможет и другим, кто сталкивается с похожим «странным поведением» BGP в ROS. Просто помните, что маршруты распространяются другим eBGP-пирами только тогда, когда они реально присутствуют и активны в стандартной таблице маршрутизации. И с нетерпением ждите новый стек BGP в ROS v7.

Читают тему

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