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-WAN и облачные сети
  4. BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста

BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста

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

    Здравствуйте, сообщество! Я столкнулся с очень странной проблемой BFD при развертывании Cisco SD-WAN (IOS-XE 17.05.04c). Хотя большинство наших сайтов, использующих один и тот же шаблон и транспорт, работают отлично, два конкретных сайта испытывают состояние BFD DOWN через частный транспорт MPLS. Настройка: Оборудование:
    C1121-4P (WAN Edge) и C8300 (DC WAN Edge).
    Транспорт 1:
    private2
    (L2VPN MPLS).
    Транспорт 2:
    biz-internet
    (Интернет).
    Конфигурация:
    Края TYPE-1 используют один
    и тот же шаблон устройства
    . Около 40 устройств на шаблон.
    Проблема:
    BFD
    private2
    к
    концентратору 1
    не работает. BFD
    private2
    к
    концентратору 2
    (тот же интерфейс/цвет/подсеть) работает. BFD
    biz-internet
    к
    концентратору 1
    работает. BFD
    biz-internet
    к
    концентратору 2
    работает. Проблема возникает только с двумя сайтами в одном городе и одним и тем же провайдером MPLS L2VPN ISP.
    private2 Данные по устранению неполадок: Доступность подстилающего уровня:
    ICMP Ping между IP-адресами TLOC успешен (размер 1400, бит DF установлен) и с DSCP.
    Парадокс трафика:

    • Edge
      show sdwan tunnel statistics
      показывает
      увеличение инкапсуляции (tx-pkts)
      .
      Hub 1
      monitor capture
      на
      физическом интерфейсе (VPN 0 ingress)
      показывает
      НУЛЕВОЕ количество пакетов,
      поступающих с этих краев.
      Счетчики:
      SdwanImplicitAclDrop
      присутствуют, но
      не увеличиваются
      . Это не несоответствие TLOC/SPI.
      Аномалии в графическом интерфейсе vManage:
      При использовании инструмента
      «Устранение неполадок» -> «Обнаружение подстилающего
      уровня» vManage не видит «Remote Transport Private2» для этих конкретных пар (от края к концентратору 1 и наоборот).
      Классификация SLA:
    • Вывод
      show sdwan tunnel remote-system-ip * sla
      для
      работающего
      Hub 2 показывает все сопоставленные классы SLA (
      Realtime, Business-Critical
      и т. д.).
      Однако для
      неработающего
      Hub 1 отображается только
      all_tunnels
      . Это подтверждает, что BFD никогда не был достаточно работоспособным, чтобы политика App-route могла даже оценить соединение.
      Контекст масштабирования:
      Многие другие маршрутизаторы на разных сайтах используют того же
      private2
      провайдера и тот же Hub 1 без каких-либо проблем. Ограничения:
      Клиент указывает на успешный ICMP-ping как доказательство того, что провайдер MPLS не виноват. Однако многие другие сайты используют тот же шаблон/провайдера/Hub и работают отлично. Вопросы: Как Edge может сообщать об успешной инкапсуляции/TX, если физический интерфейс Hub ничего не видит?
      Почему vManage Underlay Discovery не работает, если существует базовая IP-доступность?
      Есть ли какие-либо известные ошибки на уровне ASIC в C1121-4P, из-за которых он не может передавать инкапсулированные пакеты на физический провод при определенных условиях MTU/L2VPN? Буду очень благодарен за любую помощь!
    1 ответ Последний ответ
    0
    • N Не в сети
      N Не в сети
      N9Kway
      написал в отредактировано
      #2

      Привет,
      @Cristian Matei.
      У меня есть новости — проблема наконец-то
      решена
      . Я решил изменить настроенный IP-адрес на физическом интерфейсе TLOC для
      private2
      , и сразу после этого изменения сеанс BFD заработал. Честно говоря, это довольно странно, потому что для перехода на новую платформу мы выделили совершенно
      новую подсеть IPv4
      , поэтому, по логике, не должно было быть никаких конфликтов или дубликатов IP-адресов. Я также проверил записи ARP на наличие устаревших. Однако изменение IP-адреса явно устранило любую существующую блокировку. Большое спасибо за ваше время и помощь в процессе устранения неполадки! С уважением,
      Дмитрий Ратошнюк

      1 ответ Последний ответ
      0
      • C Не в сети
        C Не в сети
        Cristian Matei
        написал в отредактировано
        #3

        Привет, @N9Kway
        Обычно я не отхожу от таких сценариев, не выяснив причину, поскольку это может повлиять на меня в будущем. Я лично видел такое постоянное поведение на SDWAN, поэтому один из вариантов заключается в том, что на этом уровне что-то застряло (единственный способ выяснить это — удалить конфигурацию маршрутизатора и настроить его заново). В противном случае, может быть что-то на стороне транспорта, связанное с этим конкретным IP. Удачи, Кристиан.

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

          Привет, @N9Kway
          Что касается описанного поведения, я бы сказал, что, скорее всего, вы столкнулись с ошибкой. Думаю, вы уже пробовали перезагрузить устройство, верно? Если нет, попробуйте. Если у вас установлена версия 17.05.04c, то она больше не доступна для загрузки, что говорит о многом, а именно о том, что это была не очень удачная версия. В ней было много ошибок, связанных с BFD. Поскольку обновления SDWAN сопровождаются как исправлениями, так и дополнительными проблемами, я предлагаю попробовать обновить удаленное/филиальное устройство до первой версии MD после 17.5, а именно 17.16.8a MD или 17.9.8 MD. Спасибо, Кристиан.

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

            Привет, Кристиан, Спасибо за предложение. Прошу прощения за опечатку в моем первоначальном сообщении относительно версии программного обеспечения; я не хотел вводить вас в заблуждение. На самом деле мы используем версию
            17.15.04c
            , которая в настоящее время является
            рекомендуемой версией
            . После первоначальной проверки подключения и подтверждения того, что другие сайты с идентичными параметрами работают правильно в рамках этого шаблона, я перезагрузил как WAN Edge филиала, так и WAN Edge ЦОД, но проблема осталась. Что касается вашей рекомендации по поводу
            17.16.8a MD
            , я заметил, что в настоящее время для загрузки доступна только версия
            17.16.1a (ED)
            . Учитывая, что это версия раннего развертывания, я немного сомневаюсь, стоит ли переходить на нее в производственной среде, если она не решает конкретно эту проблему с BFD/UDP. Поскольку я уже использую самую последнюю версию (17.15.x), как вы думаете, это может быть регрессионная ошибка, или мне следует более тщательно изучить пересылку ASIC на этой конкретной платформе? С уважением,
            Дмитрий Ратошнюк

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

              Привет, @N9Kway
              Что касается версии ПО, было немного странно, что вы использовали 17.5, но теперь все стало понятно. Ни в коем случае не переходите с версии, которую вы используете в настоящее время, на более новые версии, включая 17.18, поскольку они совершенно не стабильны. Для обновления дождитесь 17.18.x MD и используйте ее только в том случае, если в течение 3-6 месяцев не будет выпущена другая версия MD. Просто хочу прояснить кое-что, прежде чем двигаться дальше. Вы говорите, что именно эта модель HW / SW с точно такой же конфигурацией способна построить туннель и сессию BFD к HUB1 через тот же транспорт? И только 1-2 сайта не могут этого сделать? Можете ли вы повторно развернуть шаблоны/группы конфигурации как на работающем, так и на неработающем устройстве, а затем использовать функцию
              предварительного просмотра
              , чтобы скопировать отправленную конфигурацию для обоих устройств, после чего сравнить их и убедиться, что нет никаких различий в отправленных функциях и возможностях? Развертывание прошло успешно для обоих сайтов, работающего и неработающего? Спасибо, Кристиан.

              1 ответ Последний ответ
              0
              • C Не в сети
                C Не в сети
                Cristian Matei
                написал в отредактировано
                #7

                Привет, @N9Kway
                Рад, что вы исправили это. В то же время, если у вас было IPv4-соединение в подслое между спицей и концентратором со старым IPv4-адресом, это не имеет никакого смысла, кроме как ошибка, что-то застряло, и изменение IPv4-адреса просто очистило состояние состояния машины. Если у вас есть такая возможность, можете ли вы теперь вернуть его к прежнему состоянию и посмотреть, появится ли он? Спасибо, Кристиан.

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

                  Привет, @Cristian Matei
                  , я думал точно так же, поэтому я попробовал вернуться к предыдущим IP-адресам. К сожалению, сеанс BFD сразу же прервался, как только я вернулся к прежним настройкам. Такое поведение наблюдается на обоих маршрутизаторах, которые находятся географически близко друг к другу (в радиусе 5 км) и используют одного и того же интернет-провайдера с L2VPN. Я попробовал очистить кэш ARP, но это не помогло. Я также проверил, что нет дублирования IP-адресов: когда старые адреса не назначены моим интерфейсам, они не отвечают на ping. Интересно, что я выполнил несколько других миграций в разных регионах с тем же интернет-провайдером L2VPN, с тех пор используя тот же шаблон и процесс, и эта проблема нигде больше не возникала. С уважением,
                  Дмитрий Ратошнюк

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

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

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

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

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


                  • Войти

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

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