Маршрут LISP в статусе «Route_rejected»?

[bfbcnet]

Привет, Это мой первый пост. Заранее прошу прощения, если этот вопрос слишком сложный для этого форума, но не попробуешь — не узнаешь. Ситуация такова: мы находимся в процессе перехода на SD-Access. У нас есть обычная фабрика со стандартной настройкой VN, которая работает нормально, и клиентские устройства могут выходить в Интернет и т. д. Мы также хотим попробовать использовать Guest VN, Multi-Site Remote border (или как это называется на этой неделе), чтобы некоторые из наших проводных устройств выходили в DMZ на нашем сайте, а не там, где выходит VN, несущий более корпоративный трафик. Эта функция не очень хорошо документирована и претерпела ряд изменений в рабочих процессах в разных версиях DNA. Мы используем DNA-C (это название, похоже, тоже изменилось) 2.3.5. Из-за отсутствия документации я использовал руководство здесь:
Multisite Remote Border
, чтобы все настроить. Однако клиенты на этом VN не могут выйти за пределы фабрики. Я могу пинговать интернет с Remote Border, с интерфейса loopback с тем же идентификатором, что и VN handoff для VN. Мы получаем маршрут по умолчанию, поступающий в удаленную границу через BGP. Клиентские устройства могут выполнять ping своего шлюза по умолчанию на своем пограничном узле. IP-адреса пограничных устройств отображаются как зарегистрированные на удаленной границе, которая также действует в качестве плоскости управления для этой виртуальной сети. Похоже, что проблема заключается в том, что маршрут по умолчанию из Remote Border не доходит до пограничного узла. Или, скорее, доходит, но находится в состоянии отклонения, как показано ниже в выводе из пограничного узла: ----------------------- XXXX-FEN-01#show lisp instance-id 4100 ipv4 map-cache detail
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf PUBLIC_WIRED_VN (IID 4100), 2 entries 0.0.0.0/0, время работы: 00:03:39, срок действия: 00:11:20, через map-reply, unknown-eid-forward
Источники: map-reply, static-send-map-request
Состояние: unknown-eid-forward, последнее изменение: 00:03:39, map-source: X.X.1.66
Исключение, Выходные пакеты: 8(4608 байт), счетчики неточны (~ 00:25:21 назад)
Настроен как действие адресного
пространства EID: send-map-request + инкапсуляция в прокси ETR
PETR Время работы Состояние Pri/Wgt Encap-IID Domain-ID/MH-ID Metric
X.X.1.66 00:30:32
route-rejec
10/10 - 2292703398/57510 0 ----------------------------------- Я застрял в дальнейшем устранении неполадок, так как не знаю, что означает этот статус, и поэтому не знаю, что делать дальше. Я, конечно, погуглил этот статус lisp, но не нашел никаких подходящих результатов. Кто-нибудь из сообщества может пролить свет на этот статус? Не помогает и то, что доступные руководства предназначены для более ранних версий 2.x DNA train или более ранних версий, а эта настройка/рабочий процесс претерпели много изменений. Я также прочитал руководство пользователя DNA 2.3.5, но, похоже, в нем не описаны настройки удаленных границ для нескольких сайтов, так что, возможно, эта функция больше не поддерживается? В любом случае, если кто-нибудь из сообщества может пролить свет на этот статус или указать, где это может быть описано, это было бы очень полезно.

[jalejand]

В вашем выводе: XXXX-FEN-01#show lisp instance-id 4100 ipv4 map-cache detail
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf PUBLIC_WIRED_VN (IID 4100), 2 entries 0.0.0.0/0, время работы: 00:03:39, срок действия: 00:11:20, через map-reply, unknown-eid-forward
Источники: map-reply, static-send-map-request
Состояние: unknown-eid-forward, последнее изменение: 00:03:39, map-source: X.X.1.66
Исключение, Выходные пакеты: 8 (4608 байт), счетчики неточны (~ 00:25:21 назад)
Настроен как действие адресного
пространства EID: send-map-request + инкапсуляция в прокси ETR
PETR Время работы Состояние Pri/Wgt Encap-IID Domain-ID/MH-ID Metric
X.X.1.66 00:30:32
route-rejec
10/10 - 2292703398/57510 0 XXXX-FEN-01 имеет состояние route-reject для X.X.1.66, что означает, что вам необходимо проверить RIB (не CEF, так как на него может влиять SGT или рекурсивное/отслеживающее состояние) для этого префикса. У вас должен быть маршрут /32 для этого X.X.1.66, каков результат команды «show ip route X.X.1.66»?

[Andrii Oliinyk]

Привет,
судя
по приведенному выше выводу,
X.X.1.66 считается PETR для вашего сайта для указанного VN. Вы проверили наличие устаревшего маршрута 0.0.0.0 в целевом VRF на PETR?

[jalejand]

Отказ маршрута означает, что вы не соответствуете критериям доступности для этого RLOC.
Границы используют: ipv4 locator reachability exclude-default
Края используют: ipv4 locator reachability minimum-mask-lenght 32
Это отслеживает доступность RLOC с помощью подстилающего (глобального) RIB.
Первый требует любого маршрута, кроме маршрута 0.0.0.0/0, чтобы сделать его доступным.
Второй требует маршрута /32, чтобы сделать его доступным.
В любом случае, я рекомендую использовать /32, а не сводки, чтобы добиться более быстрой конвергенции в любом сценарии.

[Andrii Oliinyk]

Это не очень полезное объяснение. Что нужно проверить на EN? Что нужно проверить на BN?
Из вашего ответа следует, что нужно проверить, есть ли у RLOC PETR запись /32 в подстилающем RIB на EN или какая-либо менее конкретная, кроме 0.0.0.0/0? В конечном итоге, разве это не то, что должно быть настроено как на EN, так и на BN с помощью DNAC?

[jalejand]

RLOC — это X.X.1.66 в XXXX-FEN-01, поэтому, исходя из того, что я сказал, он должен проверить критерии доступности на FEN01 до x.x.1.66. Используется ли маршрут 0.0.0.0/0 для достижения этого RLOC в глобальном RIB? Если да, измените подложку, чтобы объявить /32 до x.x.1.66.

[Andrii Oliinyk]

@bfbcnet
попробуйте это sho ip cef
X.X.1.66 в глобальном или VRF
[контексте@jalejand]
позвольте мне спросить вас еще раз: пока диагностика все еще остается делом команд CLI, разве настройка подстилающего уровня, маршрутизатора lisp и маршрутизатора bgp DNAC не является задачей, призванной сократить ручную работу, так тщательно разработанную Cisco SDA?

[jalejand]

Если вся подстилка была спроектирована с помощью DNAC (автоматизация локальной сети), то да, настроенная подстилка ISIS не будет иметь возможности суммирования или блокирования объявлений /32. Однако, если это удаленная граница с несколькими сайтами, это часто означает, что между FE и MSRB уже существует другой тип подстила, который DNAC не может контролировать или управлять. Эти условия доступности подстила (/32, исключение по умолчанию и т. д.) к сожалению не могут быть ослаблены, так как это может принести больше вреда, чем пользы (черные дыры и другие сценарии потери трафика).

[Andrii Oliinyk]

Так что... есть кое-что, что DNAC не может управлять в SDA, это жаль.
Спасибо за объяснения.

[bfbcnet]

Спасибо за ответы. Отвечу на несколько поднятых вопросов. Адрес Loopback пограничного узла может пинговать удаленный пограничный узел, и то же самое в обратном направлении для адреса Loopback удаленного пограничного узла. Кроме того, Loopback с тем же ID, что и VLAN, назначенный для VN, может достигать интернет-адреса. ------------------------------
REMOTE-BORDER#ping X.X.1.97 source loopback 0
Введите последовательность символов для прерывания.
Отправка 5 ICMP-эхо-сообщений размером 100 байт на X.X.1.97, таймаут 2 секунды:
пакет отправлен с исходным адресом X.X.1.66
!!!!!
Успешность 100 процентов (5/5), минимальное/среднее/максимальное время прохождения = 2/2/2 мс REMOTE-BORDER #ping vrf PUBLIC_WIRED_VN 8.8.8.8 source lo2XX
Введите последовательность символов для прерывания.
Отправка 5 ICMP-эхо-сообщений размером 100 байт на 8.8.8.8, таймаут 2 секунды:
пакет отправлен с исходным адресом X.X.10.1
!!!!!
Успешность 100 процентов (5/5), минимальное/среднее/максимальное время прохождения в обе стороны = 10/11/13 мс ---------------- EDGE-NODE#ping X.X.1.66 источник loopback 0
Введите последовательность символов для прерывания.
Отправка 5 ICMP-эхо-сообщений размером 100 байт на X.X.1.66, таймаут 2 секунды:
пакет отправлен с исходным адресом X.X.1.97
!!!!!
Успешность 100 процентов (5/5), минимальное/среднее/максимальное время прохождения в обоих направлениях = 2/2/2
мс-------------------------------- На удаленном границе у него есть маршрут по умолчанию, подаваемый BGP для VN, через L3 Handoff, который был настроен через DNAC, как показано ниже. Это, по-видимому, находится в таблице LISP на удаленном границе. -----------------------------------------
REMOTE-BORDER#show ip route vrf PUBLIC_WIRED_VN -Snip- Шлюз последней инстанции — X.X.9.2 для сети 0.0.0.0 B* 0.0.0.0/0 [20/0] через X.X.9.2, 00:00:
29-Snip- REMOTE-BORDER#show lisp instance-id 4100 ipv4 database
LISP ETR IPv4 Mapping Database for LISP 0 EID-table vrf PUBLIC_WIRED_VN (IID 4100), LSBs: 0x1
Entries total 53, no-route 0, inactive 0, do-not-register 0 0.0.0.0/0, набор локаторов DEFAULT_ETR_LOCATOR, ETR по умолчанию
Время работы: 00:11:35, Последнее изменение: 00:10:18
Идентификатор домена: local
Метрика: 0
Вставка службы: N/A
Локатор Pri/Wgt Источник состояния
X.X.1.66 10/10 cfg-intf site-self,
доступно---------------------- Для пограничного узла выход осуществляется через его границу фабрики, чтобы попасть через подстилающую сеть к удаленной границе. Эта граница имеет специфический маршрут по сравнению с маршрутом по умолчанию для адреса обратной связи «удаленной границы». Это привело к GRT на пограничном узле ----------------------
SITE-BORDER#show ip route
Коды: L — локальный, C — подключенный, S — статический, R — RIP, M — мобильный, B — BGP
D — EIGRP, EX — EIGRP внешний, O — OSPF, IA - OSPF межзональная
N1 - OSPF NSSA внешний тип 1, N2 - OSPF NSSA внешний тип
2-Snip-
B X.X.1.66/32 [20/0] через X.X.253.162, 2d23h ---------------------- EDGE-NODE#sho ip cef X.X.1.66
X.X.1.66/32
nexthop X.X.254.2 TwentyFiveGigE1/1/1
nexthop X.X.254.5
TwentyFiveGigE1/1/2---------------------- Итак, я выполнил условия, чтобы не нарушить контроль доступности локатора ipv4? Или я неправильно понимаю, где эти маршруты /32 должны находиться в различных таблицах маршрутизации (Edge, site border, remote border, GRT table или VN Table), чтобы это ограничение не срабатывало? Извините, LISP для меня все еще новая область, и я не углублялся в нее заранее, поскольку, возможно, ошибочно полагал, что DNAC возьмет на себя основную работу по его настройке.

[bfbcnet]

Привет, Еще раз спасибо за все комментарии. Загадка решена. Пограничный узел имел /32 для X.X.1.66 (через BGP L3 handoff), но Fabric Edge Node (FEN-01) — нет. Это было связано с тем, что маршруты BGP на границе не были полностью перераспределены в протокол маршрутизации Underlay для фабрики (IS-IS). Поэтому я вошел в пограничный узел и вручную ввел перераспределение BGP в IS-IS. Да, это было сделано только для того, чтобы проверить, что происходит. В будущем я буду использовать шаблон вместо CLI. Я как-то предполагал, что DNAC позаботится об этом. Считаю, что я был слишком осторожен с конфигурацией, которую я продвигаю, чтобы не наступить на ноги DNAC. Для меня самым сложным было понять, что делает DNAC и что мне нужно сделать, чтобы восполнить пробелы. Еще раз спасибо за подсказки. Есть ли другие недостатки LISP, такие как необходимость /32 для определенных маршрутов, которые где-то задокументированы и о которых я должен знать? Далее нужно посмотреть, совместима ли настройка Multi-Site Remote Border с настройками IP Transit...

[Andrii Oliinyk]

Многое. Обратите особое внимание на то, что настроено на коммутируемых интерфейсах L2-handoff BN. Когда или перед тем, как развернуть новую VLAN на интерфейсе L2-handoff в конфигурации BN. В моем случае было разрешено несколько VLAN. И когда я развернул новую VLAN на интерфейсе, она не отобразилась среди разрешенных.