Skip to content
  • Категории
  • Последние
  • Метки
  • Популярные
  • Пользователи
  • Группы
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • По умолчанию (Нет скина)
  • Нет скина
Collapse

Networks Engineering

  1. Главная
  2. Сети (Routing & Switching)
  3. SD-Access
  4. Маршрут LISP в статусе «Route_rejected»?

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

Запланировано Прикреплена Закрыта Перенесена SD-Access
12 Сообщения 0 Posters 0 Просмотры
  • Сначала старые
  • Сначала новые
  • По количеству голосов
Ответить
  • Ответить, создав новую тему
Авторизуйтесь, чтобы ответить
Эта тема была удалена. Только пользователи с правом управления темами могут её видеть.
  • J Не в сети
    J Не в сети
    jalejand
    написал в отредактировано
    #2

    В вашем выводе: 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»?

    1 ответ Последний ответ
    0
    • A Не в сети
      A Не в сети
      Andrii Oliinyk
      написал в отредактировано
      #3

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

      1 ответ Последний ответ
      0
      • J Не в сети
        J Не в сети
        jalejand
        написал в отредактировано
        #4

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

        1 ответ Последний ответ
        0
        • A Не в сети
          A Не в сети
          Andrii Oliinyk
          написал в отредактировано
          #5

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

          1 ответ Последний ответ
          0
          • J Не в сети
            J Не в сети
            jalejand
            написал в отредактировано
            #6

            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.

            1 ответ Последний ответ
            0
            • A Не в сети
              A Не в сети
              Andrii Oliinyk
              написал в отредактировано
              #7

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

              1 ответ Последний ответ
              0
              • J Не в сети
                J Не в сети
                jalejand
                написал в отредактировано
                #8

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

                1 ответ Последний ответ
                0
                • A Не в сети
                  A Не в сети
                  Andrii Oliinyk
                  написал в отредактировано
                  #9

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

                  1 ответ Последний ответ
                  0
                  • B Не в сети
                    B Не в сети
                    bfbcnet
                    написал в отредактировано
                    #10

                    Спасибо за ответы. Отвечу на несколько поднятых вопросов. Адрес 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 возьмет на себя основную работу по его настройке.

                    1 ответ Последний ответ
                    0
                    • B Не в сети
                      B Не в сети
                      bfbcnet
                      написал в отредактировано
                      #11

                      Привет, Еще раз спасибо за все комментарии. Загадка решена. Пограничный узел имел /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...

                      1 ответ Последний ответ
                      0
                      • A Не в сети
                        A Не в сети
                        Andrii Oliinyk
                        написал в отредактировано
                        #12

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

                        1 ответ Последний ответ
                        0

                        Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.

                        Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.

                        С вашими комментариями этот пост может стать ещё лучше 💗

                        Зарегистрироваться Войти
                        Ответить
                        • Ответить, создав новую тему
                        Авторизуйтесь, чтобы ответить
                        • Сначала старые
                        • Сначала новые
                        • По количеству голосов


                        • Войти

                        • Нет учётной записи? Зарегистрироваться

                        • Login or register to search.
                        • Первое сообщение
                          Последнее сообщение
                        0
                        • Категории
                        • Последние
                        • Метки
                        • Популярные
                        • Пользователи
                        • Группы