В одной из прошлых статей я описал способ реализации L3VPN поверх DMVPN, который позволяет организовать связность spoke-маршрутизаторов между собой напрямую, без необходимости отправлять трафик через hub. Одним из ключевых элементов этого способа было использование internal BGP labeled unicast (iBGP LU) для распределения транспортных меток. Поначалу я считал, что модифицировать схему с использованием eBGP не составит большого труда; однако, как показала практика, всё оказалось не так просто. Большая часть технологий не зависит от типа BGP и, как следствие, остаётся неизменной, поэтому можно опустить детали и упростить схему DMVPN до L2-сегмента, поверх которого будет впоследствии настроен eBGP LU: Switch1 эмулирует DMVPN-облако, на данном этапе детали его реализации нам безразличны. CSR3 выполняет роль, похожую по функциональности на hub – в его задачи входит распределение префиксов между spoke-маршрутизаторами R1 и R2. Обычно для лабы я использую образы Cisco 7200, но в этот раз мне понадобится более свежее ПО, хотя бы IOS XE Denali 16.3.1. Начальная конфигурация довольно проста: Поскольку мы планируем использовать eBGP, CSR3 не может быть route-reflector для R1 и R2. Однако все маршрутизаторы подключены к одному L2-сегменту, поэтому CSR3 не будет менять next-hop при передаче префиксов между соседями в этом сегменте. Стоит отметить, что, согласно BGP RFC, такое поведение опционально, а значит, может отличаться для другого ПО, оборудования, производителя и т.д.: When sending a message to an external peer, X, and the peer is one IP hop away from the speaker: <irrelevant part omitted> Otherwise, if the route being announced was learned from an external peer, the speaker can use an IP address of any adjacent router (known from the received NEXT_HOP attribute) that the speaker itself uses for local route calculation in the NEXT_HOP attribute, provided that peer X shares a common subnet with this address.  This is a second form of "third party" NEXT_HOP attribute. Вольный перевод: Если маршрут объявлен внешним соседом, маршрутизатор может использовать любой IP-адрес (из полученных через атрибут NEXT_HOP) в качестве NEXT_HOP при условии, что он использует этот IP-адрес для своей локальной таблицы маршрутизации и адрес соседа Х, которому будет послан маршрут, находится в той же подсети, что и IP-адрес в атрибуте NEXT_HOP. И последнее перед непосредственной настройкой BGP: R1 и R2 используют один и тот же номер AS в целях масштабируемости, поэтому нам необходимо немного поправить логику BGP в части предотвращения петель маршрутизации. Вначале настроим обычный BGP IPv4 AF без LU: Следует ожидать, что префиксы на R1 и R2 будут иметь адреса друг друга в качестве next-hop вместо адреса CSR3: Настало время включить BGP LU для IPv4 AF: Проверим, что BGP сошёлся так, как мы ожидаем: Проблема, подходящая для отладки пятничным вечером: мы не только увеличили число маршрутов в таблице BGP (обратите внимание на 1.1.1.1/32), но и испортили путь – маршрут от R1 до R2 перестал быть оптимальным.   Возможно, вы помните из предыдущей статьи, что BGP назначает префиксу метку в том случае, когда считает себя next-hop для этого маршрута, что позволяет маршрутизатору стать частью LSP. Давайте явно укажем, что менять next-hop не следует: Безуспешно, что, впрочем, находится в полном согласии с Configuration Guide. Однако существует вторая вариация этой настройки – с помощью route-map, хотя она должна быть подвержена тем же ограничениям, что и команда на уровне процесса BGP: По неведомой мне причине способ с route-map сработал, хотя и не должен был, согласно документации. В неопределённый момент в прошлом я находил заметку о том, что в случае с BGP LU отключить смену next-hop можно только с помощью route-map; к сожалению, мне не удалось найти этот документ при подготовке статьи, поэтому буду рад, если кто-то сможет поделиться ссылкой на него. Итак, мы восстановили прямой путь между R1 и R2. Но что насчёт «лишней» записи в таблице BGP? Почему она появилась после включения LU, но её нет после применения route-map? На первую часть вопроса ответить несложно: причина появления дубликата префикса на R1 носит название «update-group» в Cisco IOS: Вкратце смысл таков: IOS формирует обновления BGP на группу соседей, а не на каждого соседа отдельно, что позволяет сэкономить ресурсы маршрутизатора (представьте обработку full-view). Раньше мы могли контролировать это поведение с помощью peer-groups, однако этот рычаг управления отобрали оптимизировали давным-давно. R1 и R2 входят в одну группу с точки зрения политик BGP, поэтому они получают одинаковый набор маршрутов, включая их собственные. CSR3 переписывал next-hop для BGP LU, поэтому собственный маршрут с новым next-hop был вполне корректным с точки зрения процессов BGP на R1 и R2. Но почему же собственные префиксы на попадают в таблицу BGP, когда next-hop неизмéнен? Расспросим очевидцев: Ларчик просто открывался: если next-hop для префикса совпадает с адресом получившего его маршрутизатора, то последний просто отбрасывает такое сообщение. Очевидно, что то же самое происходит не только в случае eBGP, но и в случае iBGP (например, с использованием RR). Вернёмся к MPLS: Как легко заметить, связности по MPLS между R1 и R2 нет. Причина этого проста – отсутствуют метки. Мы используем BGP для распространения меток, поэтому, должно быть, что-то пошло не так с обновлениями BGP. Посмотрим на R1: R1 не получил меток от CSR3 ни напрямую (назначены CSR3), ни косвенно (назначены R2, CSR3 всего лишь пересылает). Однако с точки зрения CSR3 все метки на месте: Похоже на то, что CSR3 перестал отправлять своим соседям метки вместе с префиксами после применения route-map. Попробуем исправить положение так же, как мы сделали для next-hop: Проверим, поменялось ли что-нибудь на R1? Теперь R1 получает верную метку для префикса 2.2.2.2/32, однако, в обновлении для 3.3.3.3/32 она отсутствует; CSR3 игнорирует метку для этого префикса при добавлении его в BGP: Disclaimer: всё, что написано далее, получено методом проб и ошибок без опоры на официальную документацию. Итак, используем чёрную магию route-map ещё раз. 3.3.3.3/32 попадает в единственную запись NH_UNCHANGED, однако, у него нет другого next-hop, кроме CSR3, поэтому команда “next-hop unchanged” может вызывать исключение при обработке, что в свою очередь предотвращает добавление метки к обновлению BGP. Используем prefix-list для определения префиксов, которые DMVPN hub добавляет в BGP: Вуаля! Все метки на месте. Может ли R1 построить LSP до 2.2.2.2/32? LSP не сформирован: R1 не устанавливает метки в LFIB несмотря на то, что получил их по BGP. Вся информация, необходимая для построения LSP, у R1 есть, кроме, возможно, соответствия сценарию применения: R1 должен передавать трафик дальше, используя LDP, т. к. P-маршрутизатор, который использует лишь BGP – явление противоестественное. Хотел бы отдельно отметить, что это лишь догадки, основанные на рабочей конфигурации. Настало время раскрыть заклинание: Такая нехитрая настройка заставляет R1 установить метки в LFIB, при этом база данных OSPF остаётся пустой, т.к. процессу не принадлежит ни одного интерфейса. Последний факт позволяет не настраивать фильтрацию при redistribution: Удаление процесса OSPF после установки меток не приводит к очистке LFIB, однако, новые метки в LFIB уже не попадают – прекрасный повод применить знания EEM DevOps :) То же поведение можно наблюдать и для iBGP: метки не попадают в LFIB, пока «процессы-доноры», OSPF и LDP, не будут инициализированы. Впрочем, довольно копаться во внутренностях IOS, давайте посмотрим, поднялся ли LSP: Наконец, LSP между R1 и R2 заработал, остальная часть настроек L3VPN совпадает с предыдущей схемой. Наибольшей проблемой при использовании eBGP для реализации L3VPN поверх DMVPN является необходимость использования команды “next-hop unchanged”, поддержка которой для labeled unicast, по-видимому, отсутствует. Очевидно, что использование этой команды в подобной схеме умножает техническую поддержку производителя на ноль. Даже несмотря на то, что мне удалось заставить эту функцию работать в рамках подготовки статьи, нет гарантий, что это поведение не изменится в будущих версиях ПО; я бы подвергал такому испытанию только лабораторный стенд. В целом выходит, что на данный момент eBGP не подходит для построения LSP напрямую между spoke для использования в рамках L3VPN поверх DMVPN. И последнее: любознательный читатель, мы сделали домашку! Спасибо за рецензию: Анастасии Куралевой  Системный инженер