Узел Fabric Edge не пересылает запрос DHCP на узел PETR/Border.

Reply to Узел Fabric Edge не пересылает запрос DHCP на узел PETR/Border. on Fri, 13 Feb 2026 20:11:35 GMT

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

Есть ли причина, по которой вы не используете LISP Pub/Sub? Это рекомендуемая архитектура маршрутизации CP на будущее. Удалось настроить лабораторию в том же состоянии, что и ваша. Из CLI Edge Node, работающего под той же версией IOS XE, где PETR /32 отсутствует в RIB: S-EN#show run | i petr
use-petr 192.168.8.38
S-EN#
S-EN#show ip route 192.168.8.
38% Сеть отсутствует в таблице
S-EN#
S-EN#lig instance-id 4099 172.20.100.110
Информация о сопоставлении для EID 172.20.100.110 от 192.168.8.38 с RTT 1 мс
128.0.0.0/1, время работы: 00:00:00, срок действия: 00:14:59, через map-reply, forward-native
Инкапсуляция в прокси ETR
S-EN#
S-EN#show lisp instance-id 4099 ipv4 map-cache
LISP IPv4 Кэш сопоставлений для LISP 0 EID-таблица vrf CORP_VN (IID 4099), 3 записи 0.0.0.0/0, время работы: 00:42:44, срок действия: никогда, через static-send-map-request
Инкапсуляция в прокси ETR
10.4.6.0/24, время работы: 00:42:44, срок действия: никогда, через dynamic-EID, send-map-request
Инкапсуляция в прокси ETR
128.0.0.0/1, время работы: 00:00:10, срок действия: 00:14:50, через map-reply, forward-native
Инкапсуляция в прокси ETR
S-EN#
S-EN#show ip cef vrf CORP_VN 172.20.100.110 detail
128.0.0.0/1, эпоха 0, флаги [проверка соответствия LISP]
LISP удаленный EID: 2 пакета 1152 байт fwd action fwd native
LISP fwd-native source
Зависимый охватываемый префикс типа LISP-FWD, охват 0.0.0.0/0
1 IPL source [без флагов]
присоединен к LISP0.4099
S-EN# А теперь те же команды, когда PETR /32 присутствует в RIB. Обратите внимание, что в отличие от первого сценария, во втором сценарии nexthop заполняется в CEF: S-EN#show run | i petr
use-petr 192.168.8.38
S-EN#
S-EN#show ip route 192.168.8.38 Запись
маршрутизации для 192.168.8.38/32
Известно через «isis», расстояние 115, метрика 20, тип level-2
Перераспределение через isis
Последнее обновление от 172.31.218.66 на TenGigabitEthernet1/1/3, 00:00:17 назад Блоки
дескрипторов маршрутизации:

172.31.218.66, от 172.31.218.64, 00:00:17 назад, через TenGigabitEthernet1/1/3
Метрика маршрута — 20, количество долей трафика — 1
S-EN#
S-EN#lig instance-id 4099 172.20.100.110
Информация о сопоставлении для EID 172.20.100.110 от 192.168.8.38 с RTT 2 мс
128.0.0.0/1, время работы: 00:02:07, срок действия: 00:14:59, через map-reply, forward-native
Инкапсуляция в прокси ETR
S-EN#
S-EN#show lisp instance-id 4099 ipv4 map-cache
LISP IPv4 Кэш сопоставлений для LISP 0 EID-таблица vrf CORP_VN (IID 4099), 3 записи 0.0.0.0/0, время работы: 00:44:48, срок действия: никогда, через static-send-map-request
Инкапсуляция в прокси ETR
10.4.6.0/24, время работы: 00:44:49, срок действия: никогда, через dynamic-EID, send-map-request
Инкапсуляция в прокси ETR
128.0.0.0/1, время работы: 00:02:14, срок действия: 00:14:53, через map-reply, forward-native
Инкапсуляция в прокси ETR
S-EN#
S-EN#show ip cef vrf CORP_VN 172.20.100.110 detail
128.0.0.0/1, эпоха 0, флаги [контекст поддерева, проверка соответствия LISP]
SC owned,sourced: LISP remote EID - биты статуса локатора 0x00000000
LISP remote EID: 2 пакета 1152 байт действие fwd encap
LISP список путей
источника nexthop 192.168.8.38 LISP0.4099
2 источника IPL [без флагов]
nexthop 192.168.8.38 LISP0.4099
S-EN#

Reply to Узел Fabric Edge не пересылает запрос DHCP на узел PETR/Border. on Fri, 13 Feb 2026 20:11:34 GMT

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

Рассмотрение дела в TAC будет быстрее, чем в форуме.
![:grinning_face:]
![]
![] /32 в Fabric Edge Node GRT для всех BN Lo0 является обязательным, суммарный маршрут или маршрут по умолчанию недостаточны. Лучше использовать динамический протокол, чем статический, если это возможно, предлагаю добавить BN Lo0 в ISIS. У Мишеля есть презентация, которая может помочь,
https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2024/pdf/BRKTRS-3820.pdf Если вы предпочитаете решать проблему здесь, можете отправить мне личное сообщение.

Reply to Узел Fabric Edge не пересылает запрос DHCP на узел PETR/Border. on Fri, 13 Feb 2026 20:11:33 GMT

pdomingues — Fri, 13 Feb 2026 20:11:33 GMT

Граница фабрики: IOS XE 17.90.04a C9407R
Пограничный/контрольный узел: IOS XE 17.9.4a C9410R
Команды были захвачены на соответствующих узлах, указанных жирным шрифтом. Что касается команд CLI show в верхней части, они были захвачены на границе фабрики. Fabric Edge НЕ имеет маршрута /32 underlay/GRT для пограничного узла Lo0, он имеет только маршрут ISIS L2 по умолчанию, указывающий на пограничный узел. Он может нормально достигать Lo0. Я добавил статический маршрут к Lo0 на FE, но ничего не изменилось. FE1#sh lisp instance-id 4099 ipv4 map-cache 0.0.0.0/0 Кэш сопоставления LISP IPv4 для LISP 0 EID-таблица vrf DEV_VN (IID 4099), 1 запись 0.0.0.0/0, время работы: 4d21h, срок действия: бессрочный, через static-send-map-request Источники: static-send-map-request Состояние: send-map-request, последнее изменение: 4d21h, map-source: local Исключение, исходящие пакеты: 1 (318 байт), счетчики неточны (~ 4d21h назад) Настроен как пространство адресов EID Инкапсулирование в прокси ETR FE1#lig instance-id 4099 172.20.100.110 Информация о сопоставлении для EID 172.20.100.110 от 172.21.255.1 с RTT 1 мс 172.20.0.0/16, время работы: 00:02:55, срок действия: 00:14:59, через map-reply, forward-native Инкапсуляция в прокси ETR

Reply to Узел Fabric Edge не пересылает запрос DHCP на узел PETR/Border. on Fri, 13 Feb 2026 20:11:32 GMT

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

Здравствуйте. Какая версия IOS XE? На каком устройстве вы выполнили эти команды show? Имеет ли ваш Fabric Edge Node маршрут /32 underlay/GRT для всех Border Node Lo0s? Если нет, добавьте его. Вы также можете проверить запрос/ответ/состояние контрольной плоскости из Fabric Edge Node CLI: lig instance-id 4099 172.20.100.110 show lisp instance-id 4099 ipv4 map-cache 0.0.0.0/0

Reply to Узел Fabric Edge не пересылает запрос DHCP на узел PETR/Border. on Fri, 13 Feb 2026 20:11:31 GMT

pdomingues — Fri, 13 Feb 2026 20:11:31 GMT

Я вернулся к Lisp PUB/SUB вместо LISP/BGP. Я не мог заставить его работать, пока не убедился, что на DEV VRF на узле Border+CP есть маршрут по умолчанию. Проверив таблицу маршрутизации, я понял, что для этой таблицы маршрутизации VRF не был установлен маршрут по умолчанию, и добавил статический маршрут 0.0.0.0/0, хотя я уверен, что мог бы сделать это динамически через BGP. Возможно, на следующей неделе я настрою это. Из личных сообщений с jedolphi: Вам абсолютно не нужен petr CLI на EN, он регрессивен, фактически жестко кодирует маршрут по умолчанию, окончательно удалите его и оставайтесь с Pub/Sub. Здесь сказано, что маршрут по умолчанию не работает, приоритет 255: 172.21.255.1 255/10 /- 4099 640816641/5633 По умолчанию В Pub/Sub внешний пограничный узел зарегистрирует себя в качестве ETR по умолчанию, если у него есть маршрут по умолчанию в RIB. Добавьте 0/0 в RIB на BN, а затем повторно проверьте ту же команду CLI. Если это исправит проблему, было бы здорово, если бы вы обновили обсуждение в сообществах, чтобы другие могли узнать об этом и закрыть тему. Спасибо! Это решило проблему. Если у вас возникли проблемы с подключением узла Fabric Edge в VRF и вы используете контрольную плоскость PUB/SUB, убедитесь, что в таблице маршрутизации VRF на пограничном узле есть маршрут по умолчанию.