SDA

Reply to SDA on Fri, 13 Feb 2026 20:11:08 GMT

Andrii Oliinyk — Fri, 13 Feb 2026 20:11:08 GMT

Хорошо. Похоже, я изучал LISP и BGP на одном из двух BN|CP...
Вот RIB с обоих: ![andydoesntlikeuucp_0-1722498376082.png] bc на другом BN|CP (#1) он выглядит по-другому и более разумно (маршруты имеют свои лучшие роли, как и ожидалось). В то время как на BN|CP#2 подсети, локальные для BN|CP#1 (в частности, те, которые находятся между BN|CP#1 и FNs#[12]), являются:
Запись
маршрутизации для /31
Известно через «lisp», расстояние 250, метрика 1, тип неизвестен
Перераспределение через bgp
Объявлено bgp метрика 10 route-map LISP_TO_BGP Блоки
дескрипторов маршрутизации:

напрямую подключено, через Null0

Reply to SDA on Fri, 13 Feb 2026 20:11:07 GMT

jedolphi — Fri, 13 Feb 2026 20:11:07 GMT

Привет, Энди, извини, я не понимаю, в чем твой вопрос?

Reply to SDA on Fri, 13 Feb 2026 20:11:06 GMT

Andrii Oliinyk — Fri, 13 Feb 2026 20:11:06 GMT

Привет, Джером, был
бы признателен, если бы ты еще раз затронул тему № 3.
Как я вижу, в ряде пар BN|CP, взаимодействующих между собой, есть раздел VPNV4 AF address-family vpnv4
bgp aggregate-timer 0
neighbor activate
neighbor send-community both
neighbor route-map out
exit-address-family В рамках этого пиринга BN|CP объявляют друг другу (после фильтрации по определенному RM) свои напрямую подключенные подсети, которые они используют для пиринга с FN в каждой произвольной VN. Интересно, что полученные префиксы подсетей фактически видны на BN|CP как маршруты, изученные LISP: BC0001#sho lisp eid-table vrf EXAMPLE_VN ipv4 map-cache X.Y.Z.Y/31
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf EXAMPLE_VN (IID 4099), 1 entries X.Y.Z.Y/31, время работы: 10w6d, срок действия: бессрочно, через pub-sub, завершено, локально для сайта
Источники: pub-sub
Состояние: завершено, последнее изменение: 10w6d, источник карты: MATE_BN|CP_IP
Исключение, исходящие пакеты: 2 (1152 байта), счетчики неточны (~ 10w6d назад)
Настроен как EID адресный пространство
Локатор Время работы Состояние Pri/Wgt Encap-IID
MATE_BN|CP_IP 10w6d up 10/10 -
Последнее изменение состояния up-down: 10w6d, количество изменений состояния: 1
Последнее изменение доступности маршрута: 10w6d, количество изменений состояния: 3
Последнее изменение приоритета/веса: никогда/никогда
Алгоритм RLOC-probing loc-status:
Последний отправленный RLOC-probe: никогда Имея вышеуказанную информацию, я полностью потерял представление о сути этого автоматического пиринга iBGP между произвольными BN|CP сайта...

Reply to SDA on Fri, 13 Feb 2026 20:11:05 GMT

perezjm — Fri, 13 Feb 2026 20:11:05 GMT

Мне удалось найти несколько сообщений, в которых рассматриваются вопросы 1 и 2, однако я не нашел ничего о том, почему DNAC настраивает пиринг iBGP между границами только в подстилающем слое/GRT.

Reply to SDA on Fri, 13 Feb 2026 20:11:04 GMT

jedolphi — Fri, 13 Feb 2026 20:11:04 GMT

Здравствуйте, исходя из предположения, что используется LISP Pub/Sub, которая является самой современной и рекомендуемой архитектурой контрольной плоскости: 1. Да, вы можете использовать ISIS (или ваш ручной IGP) между BN в подслое. Необходимость этого определяется тем, как BN1 Lo0 может достичь BN2 Lo0. К вашему сведению, большинство людей включают ISIS/IGP между BN. 2. Per-VRF IBGP между BN не требуется. 3. Пиринг IBGP осуществляется от BN к обоим CP, которые, по-видимому, в вашем проекте расположены вместе с BN. Должны быть включены VPNv4 и VPNv6 AF, это необходимо для транспортировки маршрутов L3VN BGP через Fabric Site. Эта тема очень кратко освещена в BRKENS-2816, слайды 37-40,
https://www.ciscolive.com/on-demand/on-demand-library.html?#/session/1707505512189001p6lp С уважением, Джером