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

[pdomingues]

У нас очень простая конфигурация SDA. Один пограничный узел фабрики, к которому подключаются клиенты, и один пограничный/узел плоскости управления, который подключается к остальной части нашей нефабричной среды, а именно к маршрутизатору N7K Fusion. Наш сервер DHCP находится в нефабричной среде. Когда наш клиент отправляет запрос DHCP, он попадает в пограничный узел (подтверждено захватом пакетов), а затем устанавливает опцию 82/GIaddr. Я проверил идентификаторы цепи и удаленной цепи с помощью отладки ip dhcp и подтвердил, что он устанавливает правильные RLOC, VLAN и т. д. (подтверждено встроенным захватом пакетов). Однако после этого... процесс, похоже, останавливается. Больше не появляется никаких отладок. Встроенный захват пакетов не находит никаких пакетов, покидающих интерфейсы нашего пограничного/PETR-узла, и на пограничном/PETR-узле не захватываются никакие входящие пакеты, имеющие отношение к DHCP/UDP 67+68. Я думаю, что это может иметь какое-то отношение к нашей таблице LISP? DHCP-сервер — 172.20.100.110. #sh ip cef vrf DEV_VN 172.20.0.0 det
172.20.0.0/16, epoch 0, flags [проверка соответствия LISP]
LISP удаленный EID: 48 пакетов 15266 байт fwd action fwd native
LISP fwd-native source
Зависимый покрытый префикс типа LISP-FWD, покрытие 0.0.0.0/0
1 IPL source [без флагов]
присоединен к LISP0.4099 #sh ip lisp map-cache 172.20.100.0 instance-id 4099
LISP IPv4 Mapping Cache для LISP 0 EID-таблица vrf DEV_VN (IID 4099), 1 запись 172.20.0.0/16, время работы: 00:29:58, срок действия: 00:14:38, через map-reply, forward-native
Источники: map-reply
Состояние: forward-native, последнее изменение: 00:29:58, map-source: 172.21.255.1
Активно, исходящие пакеты: 48 (15266 байт), счетчики неточны (~ 00:00:22 назад)
Инкапсуляция в прокси ETR Не знаю, какие шаги предпринять и что делать дальше. Я могу пинговать DHCP-сервер с fusion router. Я могу пинговать DHCP-сервер из глобальной таблицы маршрутизации и из DEV_VN VRF на пограничном узле (при условии, что он исходит из центра Loopback DNA, созданного на границе). Я могу пинговать DHCP-сервер из глобальной таблицы маршрутизации, но НЕ из DEV_VN VRF на краевой части фабрики. Должен ли я иметь возможность пинговать адрес PETR RLOC из DEV_VN VRF на краевой точке фабрики? Возможно ли, что он не знает, как достичь PETR из VRF, и в этом заключается проблема? Я могу пинговать PETR RLOC из глобальной таблицы маршрутизации на краевой точке фабрики, но не из VN VRF. DHCP-сниффинг включен с правильными подключенными VLAN, граница фабрики настроена как PITR, опция 82 originate включена... Не знаю, в чем я ошибаюсь. Спасибо. Дополнительная информация: Fabric Edge LISP — Информация, применимая ко всем экземплярам EID:
Router-lisp ID: 0
Таблица локаторов: по умолчанию
Маршрутизатор входного туннеля (ITR): отключен
Маршрутизатор выходного туннеля (ETR): включен
Маршрутизатор прокси-ITR (PITR): включен RLOC: 172.21.255.2
Маршрутизатор прокси-ETR (PETR): отключен
Маршрутизатор NAT-traversal (NAT-RTR): отключен Маршрутизатор первого
прыжка мобильности: отключен Сервер
карт (MS): отключен
Резолвер карт (MR): отключен
Mr-use-petr: отключен
Первый пакет pETR: отключен
Поддержка нескольких IP-адресов на MAC: отключена
Делегированное дерево базы данных (DDT): отключено Туннель доступа
к многоадресной рассылке: отключен
Публикация-подписка: включена
Издатель(и): *** НЕ НАЙДЕНО ***
ITR Map-Resolver(s): 172.21.255.1
ETR Map-Server(s): 172.21.255.1
xTR-ID: 0x570C1D3C-0x75B2B221-0x8FB89F16-0x428F42C4
site-ID: не указан
ITR local RLOC (last resort): *** НЕ НАЙДЕНО ***
ITR использовать прокси ETR RLOC (Encap IID): 172.21.255.1 Пограничный узел LISP - Информация, применимая ко всем экземплярам EID:
Router-lisp ID: 0
Таблица локаторов: по умолчанию
Входной туннельный маршрутизатор (ITR): отключен
Выходной туннельный маршрутизатор (ETR): включен
Прокси-ITR маршрутизатор (PITR): включен RLOC: 172.21.255.1
Маршрутизатор прокси-ETR (PETR): включен
Маршрутизатор NAT-traversal (NAT-RTR): отключен Маршрутизатор первого
прыжка мобильности: отключен Сервер
карт (MS): включен
Резолвер карт (MR): включен
Mr-use-petr: включен
Mr-use-petr locator set name: default-etr-locator-set-ipv4
First-Packet pETR: отключен
Поддержка нескольких IP-адресов на MAC: отключена
Delegated Database Tree (DDT): отключена
Multicast Flood Access-Tunnel: отключен
Publication-Subscription: включен
Publisher(s): *** НЕ НАЙДЕНО ***
ITR Map-Resolver(s): 172.21.255.1
ETR Map-Server(s): 172.21.255.1

[pdomingues]

Я вернулся к 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 на пограничном узле есть маршрут по умолчанию.

[jedolphi]

Здравствуйте. Какая версия 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

[pdomingues]

Граница фабрики: 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

[jedolphi]

Рассмотрение дела в 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 Если вы предпочитаете решать проблему здесь, можете отправить мне личное сообщение.

[jedolphi]

Есть ли причина, по которой вы не используете 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#