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

Фильтр BGP по атрибутам cluster-list и originator-id для EBGP-соседей

Фильтр BGP по атрибутам cluster-list и originator-id для EBGP-соседей, RouterOS

netzwerghh

Guest

08.11.2023 15:08:00

Привет! Можно ли удалить эти атрибуты у маршрутов, рекламируемых eBGP-пирами через фильтр? У нас есть некоторые нижестоящие AS, которые получают от нас маршруты. Эти атрибуты внедряются в BGP-маршруты, распространяемые через наши внутренние route reflector'ы Bird. На наших собственных маршрутизаторах эта информация полезна — так мы можем отследить, откуда маршруты изначально попали в нашу сеть. Но эту информацию не следует передавать дальше во внешний ASN. Спасибо, Деннис.

sri2007

Guest

08.04.2024 21:38:00

Это становится важным: сегодня мы обнаружили проблему с eBGP-пиром, у которого на другом конце Huawei или Cisco роутер. Процесс отладки показывает, что они получают cluster-list и originatorid в качестве части атрибутов BGP, из-за чего по умолчанию маршруты отбрасываются. Пример (из моей лаборатории):

Apr 8 2024 21:26:24.280.2 HUAWEI RM/6/RMDEBUG: BGP.Public : Ошибка при получении сообщения UPDATE от пира 172.16.x.1, игнорировано. Причина: (получен атрибут ORIGINATORID от EBGP).
Apr 8 2024 21:26:24.280.3 HUAWEI RM/6/RMDEBUG: BGP.Public : Ошибка при получении сообщения UPDATE от пира 172.16.x.1, игнорировано. Причина: (получен атрибут CLUSTERLIST от EBGP).
Apr 8 2024 21:26:24.280.4 HUAWEI RM/6/RMDEBUG: BGP: маршруты из сообщения update должны обрабатываться как withdrawn из-за причин, указанных выше.
Apr 8 2024 21:26:24.280.5 HUAWEI RM/6/RMDEBUG: BGP.Public: получено UPDATE от 172.16.x.1 с такими направлениями: Длина сообщения update: 91 MP_reach: AFI/SAFI 1/1 origin: IGP AS Path: XXXX YYYY next hop: 172.16.x.1 community: aaaa:bbbb
BGP.Public: получено UPDATE(Withdraw) сообщение от 172.16.x.1 с направлениями: 2.19.162.0/24

Если у вас пиринг (eBGP) с Juniper или любым другим Mikrotik — всё работает без проблем, с другими платформами пока не проверял.

Вот лог с другого Mikrotik (версия 6):
05:36:56 route,bgp,debug,packet UPDATE Message
05:36:56 route,bgp,debug,packet RemoteAddress=10.x.x.2
05:36:56 route,bgp,debug,packet MessageLength=91
05:36:56 route,bgp,debug,packet
05:36:56 route,bgp,debug,packet PathAttributes
05:36:56 route,bgp,debug,packet bgp-origin=IGP
05:36:56 route,bgp,debug,packet bgp-as-path=XXXX,YYYY
05:36:56 route,bgp,debug,packet bgp-as-path-len=2
05:36:56 route,bgp,debug,packet bgp-aggregator-as=3427860480
05:36:56 route,bgp,debug,packet bgp-aggregator-address=2.162.19.2
05:36:56 route,bgp,debug,packet bgp-communities={aaaa:bbbb}
05:36:56 route,bgp,debug,packet bgp-originator-id=151355236
05:36:56 route,bgp,debug,packet bgp-cluster-list={ 235372388, 33554432 }
05:36:56 route,bgp,debug,packet
05:36:56 route,bgp,debug,packet NLRI=2.19.162.0/24

Основной роутер, отправляющий эти апдейты — CCR2216 с версией 7.13.5.

netzwerghh

Guest

09.04.2024 09:55:00

Спасибо, sri2007, это именно наша проблема. У нас двое клиентов используют оборудование Cisco, и логи их устройств заполняются сообщениями о BGP-объявлениях с такими атрибутами.

Для разработчиков Mikrotik: RFC4456 (вводит отражение маршрутов и описанные атрибуты, https://datatracker.ietf.org/doc/html/rfc4456) в пункте 8 говорит следующее: при отражении маршрута из-за неправильной настройки могут возникать петли перераспределения маршрутов. Метод отражения маршрутов определяет следующие атрибуты для обнаружения и предотвращения петель маршрутизации:

ORIGINATOR_ID
ORIGINATOR_ID — это новый необязательный, нетранзитивный атрибут BGP с типовым кодом 9. Этот атрибут занимает 4 байта и создаётся RR при отражении маршрута. Он содержит BGP-идентификатор источника маршрута в локальном AS. BGP-спикер НЕ ДОЛЖЕН создавать атрибут ORIGINATOR_ID, если он уже присутствует. Маршрутизатор, распознающий ORIGINATOR_ID, ДОЛЖЕН игнорировать маршрут, полученный с его собственным BGP-идентификатором в качестве ORIGINATOR_ID.

CLUSTER_LIST
CLUSTER_LIST — это новый необязательный, нетранзитивный атрибут BGP с типовым кодом 10. Это последовательность значений CLUSTER_ID, представляющих путь отражения, по которому прошёл маршрут. Когда RR отражает маршрут, он ОБЯЗАН добавлять локальный CLUSTER_ID в начало CLUSTER_LIST. Если CLUSTER_LIST пустой, он должен создать его. С помощью этого атрибута RR может определить, вернулась ли информация о маршруте обратно в тот же кластер из-за неправильной настройки. Если локальный CLUSTER_ID уже есть в CLUSTER_LIST, полученное объявление ДОЛЖНО игнорироваться.

Нетранзитивные атрибуты означают, что они не должны распространяться за пределы собственного ASN. Поэтому, если пир BGP настроен как ebgp*, эти атрибуты должны быть удалены из объявлений.

robnil

Guest

24.04.2024 15:22:00

Мы также сталкивались с этой проблемой при использовании eBGP между маршрутизатором Mikrotik 7.13.5 и Cisco IOS (XE). На Cisco появляется сообщение %BGP-6-MSGDUMP_LIMIT: unsupported or mal-formatted message received from …..: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 005C 0200 0000 4340 0101 0250 0200 0E02 0300 009A E000 009A E000 009A E040 0304 0AFA 1295 4006 00D0 0800 049A E000 01D0 1000 0800 029A E000 0000 2A80 0904 C318 BF0D 900A 0004 C318 BF0A 080A

А также %BGP-6-MALFORMEDATTR: Malformed attribute in (BGP(0) Prefixes: 10.0.0.0/8) received from ….

Мы нашли обходной путь на Cisco IOS XE, который решает эту проблему — отбрасывание этих атрибутов в входящих обновлениях eBGP. Это реализуется добавлением следующей строки в конфигурацию соседа:

neighbor ….. path-attribute discard range 9 10 in

В более старых версиях Cisco IOS эта команда path-attribute discard не поддерживается, поэтому там решить проблему этим способом нельзя.

Есть ли у вас информация о каких-либо обновлениях от Mikrotik для решения этой проблемы?

dmitris Guest	#5 0 27.04.2024 22:32:00 Пожалуйста, сообщите о таком поведении в службу поддержки Mikrotik. https://mikrotik.com/support

petkodmitriy Guest	#6 0 29.04.2024 07:48:00 Та же проблема с BGP , но в моём случае, думаю, дело в атрибуте as-path в конфедерации.

ernieball17 Guest	#7 0 23.08.2024 17:24:00 Привет! Есть какое-нибудь решение по этому поводу? У меня проблемы с атрибутом агрегатора, но на платформах UBNT.

jimmyc

Guest

17.09.2024 07:26:00

Привет! У нас тоже такая проблема на CCR 2116 с версией 7.14.3. Нижеуказанное объявление распространяется по eBGP-соседству, хотя атрибуты originator-id и cluster-list являются опциональными и не транзитивными.

/routing bgp advertisements print where dst=x.x.x.x/22 0 peer=bgp-cust-ipv4-1 dst=x.x.x.x/22 afi=ip nexthop=x.x.x.x origin=0 as-path=sequence xxxxx xxxxx xxxxxx communities=xxxxx,xxxxx,xxxxxx,xxxx originator-id=x.x.x.x cluster-list=x.x.x.x

Буду признателен за любую помощь по этому вопросу.
С уважением, Джимми

netzwerghh

Guest

24.09.2024 13:31:00

Кто-нибудь уже пробовал 7.16, который сегодня вышел в лаборатории? Там написано: *) bgp — исправлены cluster-list и originator-id; может, наконец-то починили. Сегодня времени проверить не будет, но, может, в течение недели получится.

jimmyc Guest	#10 0 25.09.2024 09:20:00 В эти выходные попробуем обновить прошивку! Если кто-то попробует сделать это раньше, дайте знать, как всё прошло. С уважением, Джимми

jimmyc

Guest

#11

28.09.2024 12:24:00

Итак, сегодня утром мы установили прошивку 7.16 и, похоже, проблема теперь решена — если только мы что-то совсем не упустили! Мы проверили несколько префиксов, которые раньше отправлялись с атрибутами cluster-list и originator-id, и их там больше нет. Также посмотрели всю таблицу маршрутизации на наличие originator-id и path-attributes — и не нашли их ни в одном из маршрутов, отправляемых на ebgp-пир:

/routing bgp advertisements print where originator-id=x.x.x.x
/routing bgp advertisements print where cluster-list=x.x.x.x

Спасибо, MikroTik! С наилучшими пожеланиями, Джимми

netzwerghh Guest	#12 0 05.10.2024 13:59:00 Мы недавно обновили все наши BGP-маршрутизаторы (6 штук CCR2216) до версии 7.16. Похоже, проблемы с cluster list теперь исчезли. Мы также проверили с помощью Wireshark — обновления BGP к нашим eBGP-пирам идут без атрибута cluster-list, а к маршрутизаторам-ретрансляторам — с ним. Значит, всё работает отлично. Мы даже заметили небольшое снижение общей загрузки CPU на наших маршрутизаторах с большим количеством пиров (на AMS-IX и DE-CIX). Отличная работа!

Читают тему

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