Это действительно очень полезная функция, о существовании которой я даже не знал, пока не искал решение для рекламирования подсети (префикса в терминологии BGP) только при наличии определенного условия. Именно это и делает условная реклама
«Функция условного объявления протокола BGP (Border Gateway Protocol) обеспечивает дополнительный контроль над объявлением маршрутов в зависимости от наличия других префиксов в таблице BGP».
Я предполагаю, что те, кто хочет прочитать этот пост, имеют некоторое представление о BGP и его использовании списков префиксов и карт маршрутов, иначе этот пост может быть трудно понять. Имейте в виду, что условное объявление является частью экзамена CCIE R&S.
Поэтому перейду сразу к сценарию:
[image: 90b5cd7379a9363a00fe3dab5a3ef0b3a7745cc1.jpg]
Маршрутизаторы в моем административном домене — 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
[image: 90b5cd7379a9363a00fe3dab5a3ef0b3a7745cc1.jpg]