Функция условного объявления BGP
-
Это действительно очень полезная функция, о существовании которой я даже не знал, пока не искал решение для рекламирования подсети (префикса в терминологии BGP) только при наличии определенного условия. Именно это и делает условная реклама
«Функция условного объявления протокола BGP (Border Gateway Protocol) обеспечивает дополнительный контроль над объявлением маршрутов в зависимости от наличия других префиксов в таблице BGP».
Я предполагаю, что те, кто хочет прочитать этот пост, имеют некоторое представление о BGP и его использовании списков префиксов и карт маршрутов, иначе этот пост может быть трудно понять. Имейте в виду, что условное объявление является частью экзамена CCIE R&S.
Поэтому перейду сразу к сценарию:
Маршрутизаторы в моем административном домене — BEN и IBM. Мой основной маршрутизатор — BEN, а диапазон публичных IP-адресов, который я объявляю, — 203.11.11.0/24.
Моими двумя интернет-провайдерами являются Telstra и Next.
BEN имеет соседа eBGP с Telstra,
IBM имеет eBGP-партнера с Next.
Затем BEN и IBM из соседства iBGP.
Пока ничего нового. Теперь я обнаружил, что при рекламировании одного и того же публичного IP-адреса (префикса) двум разным провайдерам, даже с добавлением AS-пути, попытка сделать одного интернет-провайдера более предпочтительным по сравнению с другим, является весьма непредсказуемой. Это связано с тем, что некоторые провайдеры предпочитают других провайдеров, независимо от того, как часто вы добавляете AS-путь к вашему публичному префиксу. Это может привести к асинхронной маршрутизации, когда ваш выходной путь является основным ISP, а входным — вторичным маршрутизатором. Поэтому я искал другое решение: маршрутизировать мои публичные IP-адреса только к резервному провайдеру (в моем случае Next) в случае сбоя основного. Или даже лучше: переключаться на резервный, когда основной ISP перестает рекламировать маршрут по умолчанию в мою организацию через основной маршрутизатор.
Чтобы все это реализовать, большая часть, если не вся, настройка выполняется на вторичном маршрутизаторе IBM, так что давайте приступим.
Как вы можете видеть ниже, вторичный интернет-маршрутизатор (IBM) имеет 2 шлюза по умолчанию
IBM#sh ip bgp topology *
Для семейства адресов: IPv4 Unicast
Версия таблицы BGP — 26, локальный ID маршрутизатора — 160.100.100.231
Коды состояния: s подавлен, d затухающий, h история, * действительный, > лучший, i - внутренний,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x лучший внешний, a дополнительный путь, c RIB-сжатый,
Коды происхождения: i — IGP, e — EGP, ? — неполный
Коды проверки RPKI: V действительный, I недействительный, N не найден
Сеть Следующий прыжок Метрика LocPrf Вес Путь
*>i 0.0.0.0 203.11.11.5 0 200 0 3000 i- 160.100.100.230 100 0 4000 i
Наиболее предпочтительный исходит от маршрутизатора BEN, который, в свою очередь, рекламируется маршрутизатором Telstra (23.23.23.113). Изначально я собирался использовать отслеживание ip sla на маршрутизаторе IBM для рекламы 203.11.11.0/24, если BEN потеряет соединение с Telstra, но это не так надежно, как проверка, рекламирует ли BEN по-прежнему шлюз по умолчанию, потому что, если мой основной интернет-маршрутизатор больше не отправляет маршрут по умолчанию 0.0.0.0 на мой вторичный интернет-маршрутизатор, то либо мой основной маршрутизатор не работает, либо соединение с Telstra не работает, либо Telstra по какой-то другой причине больше не рекламирует маршрут по умолчанию.
Итак, на моем IBM я настроил условное объявление для моего следующего BGP-пира:
router bgp 5000
address-family ipv4
neighbor 160.100.100.230 advertise-map ADVERTISE non-exist-map NON-EXIST
Это означает,
что
маршрутная карта
ADVERTISE
вызывается, когда условие в
маршрутной карте
NON-EXIST
больше не существует.
route-map ADVERTISE permit 10
match ip address 60
route-map NON-EXIST permit 10
match ip address prefix-list TEST
match community 1
Таким образом, карта маршрутов ADVERTISE является проще, она представляет собой наш публичный IP-префикс 203.11.11.0/24
access-list 60 permit 203.11.11.0 0.0.0.255
Карта маршрутов NON-EXIST — это условие, которое необходимо проверить, и на самом деле оно состоит из двух условий: оно проверяет префикс для определенного сообщества и проверяет, доступен ли фактический префикс в таблице BGP:
ip prefix-list TEST seq 5 permit 0.0.0.0/0
Причина наличия двух условий заключается в том, что (см. вывод sh ip bgp topology * выше) в таблице есть два префикса 0.0.0.0: по одному от каждого провайдера. Сейчас меня интересует проверка только одного из них, а именно того, который поступает от BEN 203.11.11.5. Я подумал, что проще всего будет добавить проверку определенного сообщества (хотя AS path тоже подошел бы).
ip community-list 1 permit 362000
По сути, это второе условие проверяет, имеет ли маршрут 362000 в качестве сообщества.
Вы можете проверить маршрут, чтобы увидеть, установлен ли атрибут сообщества и имеет ли он правильное значение. См. ниже
IBM#sh ip bgp 0.0.0.0
Запись таблицы маршрутизации BGP для 0.0.0.0/0, версия 25
Пути: (3 доступных, лучший #1, таблица по умолчанию)
Не объявлено ни одному пиру
Период обновления 1
3000, (получено и использовано)
203.11.11.5 от 203.11.11.5 (203.11.11.5)
Происхождение IGP, метрика 0, localpref 200, действительный, внутренний, лучший
Сообщество: 36200
rx pathid: 0, tx pathid: 0x0
Период обновления 1
4000
Таким образом, на данном этапе должны быть выполнены оба условия: а) маршрут по умолчанию в таблице BGP и б) маршрут с атрибутом сообщества 36200. Таким образом, наш общедоступный префикс 23.11.11.0/24 НЕ должен рекламироваться из IBM в Next. Для проверки:
IBM#sh ip bgp nei 160.100.100.230
Сосед BGP —
160.100.100.230
, удаленный AS 4000, внешняя ссылка
---<вывод опущен>
Карта условий NON-EXIST, карта объявлений ADVERTISE, статус:
Withdraw
---<вывод опущен>
Как видите, условное объявление имеет статус «withdraw», что означает, что условие для начала объявления не выполнено, т. е. у нас есть действительный маршрут по умолчанию, поступающий от BEN. Поэтому давайте я сделаю что-нибудь, чтобы вызвать изменение условия. Для этого я отключу соединение между Telstra и BEN. (Помните, что BEN не генерирует 0.0.0.0, он получает его от Telstra, и как только это соединение прерывается, он больше не должен получать маршрут по умолчанию).
При отладке маршрутизации на IBM:
I
BM#
*7 марта 04:45:48.908: RT: обновление bgp 0.0.0.0/0 (0x0) :
через 160.100.100.230 0 1048577
*7 марта 04:45:48.915: RT: более близкое административное расстояние для 0.0.0.0, очистка 1 маршрута
*7 марта 04:45:48.919: RT: добавление 0.0.0.0/0 через 160.100.100.230, метрика bgp [20/0]
Как видите, 0.0.0.0 от BEN удаляется из таблицы bgp. В результате срабатывает условное объявление:
I
BM#sh ip bgp nei 160.100.100.230
<опущено>
Карта условий NON-EXIST, карта объявлений ADVERTISE, статус:
Advertise
Чтобы еще раз проверить это, мы проверяем, какие маршруты маршрутизатор IBM отправляет в Next:
IBM#sh ip bgp nei 160.100.100.230 advertised-routes
Версия таблицы BGP — 13, локальный ID маршрутизатора — 160.100.100.231
Коды состояния: s подавлен, d затухающий, h история, * действительный, > лучший, i - внутренний,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x лучший внешний, a дополнительный путь, c сжатый RIB,
Коды происхождения: i - IGP, e - EGP, ? - incomplete
Коды проверки RPKI: V действительный, I недействительный, N не найден
Сеть Следующий прыжок Метрика LocPrf Вес Путь
*> 203.11.11.0/24
203.11.11.1
0 32768 i
Если у вас есть вопросы, напишите мне.
Намасте
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16137-cond-adv.html
- 160.100.100.230 100 0 4000 i
-
Привет, Деннис, спасибо, я не знал об этой возможности... Но что произойдет, если ваш основной eBGP-пир будет изолирован в сети вашего интернет-провайдера...? Конечно, можно быть уверенным, что он больше не будет рекламировать маршрут по умолчанию в направлении вашей AS, но что, если он все же будет рекламировать маршрут по умолчанию в направлении вашей сети...? Ваше публичное IP-пространство будет изолировано, потому что условие ваших маршрутных карт по-прежнему действительна: есть маршрут по умолчанию, полученный от вашего основного интернет-провайдера, поэтому вы не рекламируете свое публичное IP-пространство в адрес «резервного» интернет-провайдера... С уважением, Jeroen
-
Итак, маршрутизаторы в моей административной домене — BEN и IBM. Мой основной маршрутизатор — BEN, а диапазон публичных IP-адресов, которые я рекламирую, — 203.11.11.0/24.
Моими двумя интернет-провайдерами являются Telstra и Next.
BEN имеет соседа eBGP с Telstra,
IBM имеет eBGP-партнера Next.
Затем BEN и IBM из соседства iBGP.
Пока ничего нового. Теперь я обнаружил, что при рекламировании одного и того же публичного IP-адреса (префикса) двум разным провайдерам, даже с добавлением AS-пути, попытка сделать одного интернет-провайдера более предпочтительным по сравнению с другим, является весьма непредсказуемой. Это связано с тем, что некоторые провайдеры предпочитают других провайдеров, независимо от того, как часто вы добавляете AS-путь к вашему публичному префиксу. Это может привести к асинхронной маршрутизации, когда ваш выходной путь является основным ISP, а входным — вторичным маршрутизатором. Поэтому я искал другое решение: маршрутизировать мои публичные IP-адреса только к резервному провайдеру (в моем случае Next) в случае сбоя основного. Или даже лучше: переключаться на резервный, когда основной ISP перестает рекламировать маршрут по умолчанию в мою организацию через основной маршрутизатор. Вопрос в том, в чем вы видите проблему с асинхронной маршрутизацией? В настоящее время это происходит постоянно в публичном Интернете и не должно вызывать никаких опасений в данном примере. Условная реклама — хороший инструмент, но я не совсем уверен, что он подходит для этой ситуации. -
@Jeroen Huysmans
Вы абсолютно правы, если и когда маршрут по умолчанию по-прежнему рекламируется на основном маршрутизаторе, в то время как есть проблема с основным провайдером, то условная реклама действительно не сработает. Это не столько недостаток, сколько ограничение. То же самое происходит, когда два маршрутизатора теряют соседство iBGP и все становится splitbrain. @AARON WEINTRAUB
. Аарон. В данном сценарии нет никаких проблем с асинхронной маршрутизацией. Асинхронная маршрутизация действительно использует больше путей, чем в случае, когда ваш публичный диапазон рекламируется из одного маршрутизатора за раз. Приведенная иллюстрация ни в коем случае не является панацеей, но ее следует рассматривать как альтернативу AS path prepend. -
@AARON WEINTRAUB Если основной канал является каналом с линейной скоростью (1 Гбит без ограничения скорости), но ваш резервный канал, например, 100 Мбит с «всплеском» до 1 Гбит/с, вы будете платить за любой трафик на вашем резервном соединении, превышающий 100 Мбит/с. При равных соединениях нет проблем с асинхронной маршрутизацией, но иногда резервный канал не может обработать трафик по техническим или финансовым причинам.
-
Я подумал о том, чтобы отправить сообщество на пир eBGP интернет-провайдера и попросить его обновить локальный префикс для ваших маршрутов, чтобы он был ниже того, который они получают от пира eBGP на подключающемся интернет-провайдере. Например: Отправить сообщество xxx:50 в NEXT ISP, и тогда все маршруты, соответствующие этому сообществу, будут иметь локальный приоритет, установленный на 50, вместо того, который установлен по умолчанию для подключенного ISP. Таким образом, если трафик поступает в NEXT ISP AS, предпочтительный маршрут каким-то образом будет проходить через TELSTRA (я думаю, что ISP обычно используют локальный приоритет 70 между собой??? Нужно, чтобы это подтвердил сотрудник интернет-провайдера, но я так слышал), и затем, если этот маршрут BGP каким-то образом исчезнет через TELSTRA, процесс выбора лучшего пути будет пересчитан, и трафик будет поступать по резервному каналу в вашем AS. Я занимаюсь сетями всего около полутора лет, поэтому, пожалуйста, поправьте меня, если я что-то упустил. Но я
думаю
, что так это и работает. Я никогда не использовал функцию условного объявления, поэтому было очень интересно прочитать об этом, и я обязательно попробую это в лаборатории! Я люблю BGP, это так интересно!
]
-
@cheeseburger Это фактически стандартный способ настройки резервного канала. Провайдеры обычно имеют «по умолчанию для клиентов» для локальных предпочтений своих клиентов. Скажем, 100. Это означает, что любой трафик между их клиентами не покидает их AS, если у них есть прямое соединение. У них также есть «peer default» (например, 80), который они устанавливают для всех маршрутов, полученных от других интернет-провайдеров. Затем они обычно имеют сообщества для установки вашего локального предпочтения, скажем, от 70 до 90. Это позволит вам установить его на 70 и предпочесть другой маршрут, даже если он поступает от другого интернет-провайдера (локальное предпочтение 80). Проблема заключается в том, что не все интернет-провайдеры имеют сообщества, которые вы можете использовать для установки локальных предпочтений, и они не сообщают вам, как настроен их BGP. Также нет никаких указаний на то, как интернет-провайдеры должны настраивать свой BGP, поэтому у нас есть один провайдер, у которого значение по умолчанию составляет 140, и вы можете установить его от 90 до 150. Это требует общения с каждым провайдером, чтобы понять их настройки и то, как вы можете их настроить, чтобы они работали для вас. Часто, когда я звоню им, чтобы получить эту информацию, мне отвечает человек, который знает о BGP меньше, чем я. Для провайдеров, которые не предоставляют никакого контроля над настройкой BGP, эти условные объявления могут быть единственным способом, помимо префиксов, повлиять на вашу маршрутизацию.
-
В моем случае между моим маршрутизатором CE нет пиринга BGP. Какое решение будет в этом случае?
-
sudkampt, вы имеете в виду, что у вас есть 2 интернет-провайдера и два маршрутизатора? Но нет BGP для ваших интернет-провайдеров?
-
Есть ли способ объявления нескольких маршрутов и условий? Пример: объявлять IP1, если существует IP100 объявлять IP2, если существует IP101 объявлять IP3, если существует IP102
-
Спасибо за обзор. Я знал об этом инструменте, но вы помогли мне лучше его понять. Еще один инструмент в арсенале для решения сложных задач.
-
Здравствуйте, сообщество. Можно ли использовать as-path acl в карте маршрутов в качестве условия сопоставления? Я пробовал, но, похоже, это не работает. Возможно, эта команда проверяет только rib? Спасибо.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти