Всем привет! Я готовился к экзамену ENSDWI и выполнял некоторые лабораторные работы. Я столкнулся со странной проблемой, когда соединение BFD не формируется между соединениями MPLS и MPLS, но формируется с цветами biz-internet. Я постараюсь разъяснить сценарий, проблему и то, что я обнаружил на данный момент, а также то, в чем мне нужна помощь.
Сценарий и топология: ![Topology.png]

1. У меня есть 2 сайта DC и 3 филиала. Я приложил схему сети. Согласно схеме, TLOC продлен между BR1-1 (Интернет продлен от BR1-2) и BR1-2 WAN Edges (MPLS продлен от BR1-1). 2) Контрольные соединения работают нормально (оба транспорта), и я могу пинговать транспортную сеть с WAN Edges на всех сайтах.
2. NAT включен на транспортном интерфейсе (не включен на интерфейсе расширения TLOC).
3. biz-internet color, который был расширен от BR1-2, работает нормально и имеет все «включенные» туннели управления и BFD. (Изображение прилагается)
   ![bfdBR1.png]
   Проблема
   Итак, в BR1-2 mpls color не устанавливает соединение bfd со всеми сайтами на mpls color. Но тот же mpls color устанавливает сеансы bfd с другим транспортным цветом, как показано на изображении.
   ![bfdBR2.png] Что я обнаружил и заметил
   Во время устранения неполадки я зашел в один из маршрутизаторов филиала и увидел, что расширенный IP-адрес tloc (10.51.1.2 и 10.61.1.1) был преобразован и отображен как транспортный IP-адрес. Я имею в виду, что 10.51.1.2 (адрес интерфейса BR1-2) является расширенным IP-адресом tloc для biz-internet color и был преобразован в публичный IP-адрес biz internet 209.165.201.5 (адрес интерфейса BR1-1).
   Но для цвета mpls to mpls адрес MPLS tloc 10.51.1.2 (адрес интерфейса BR1-2) должен быть преобразован таким же образом, как biz-internet, чтобы отображаться как 192.168.20.5 на вкладке сеансов bfd, но вместо этого отображается адрес MPLS tloc. ![transl.png]
   Еще более странно то, что когда я проверяю таблицу преобразования NAT, она показывает, что преобразование выполнено. Порты в таблице преобразования и в сессиях bfd выделены на картинке ниже.
   ![natt.png]
   ![natrans.png]
   Для справки я покажу то же самое для цвета biz-internet.
   ![biznat.png]
   ![biznatt.png] Теперь самое странное: если я изменил цвет mpls на другой. Например, я изменил его на зеленый и просмотрел сеансы bfd, и вот, оно работает! При той же конфигурации и том же IP.
   ![color.png]
   Теперь мой вопрос: является ли нормальным поведением, что расширение tloc mpls не формирует сеанс bfd с другим транспортом mpls, если применяется NAT. Мне пришла в голову мысль, что теоретически sd-wan предполагает, что NAT не требуется для соединения mpls. Я буду очень благодарен за помощь экспертов в этой странной ситуации. Приношу извинения всем, кому это может показаться слишком длинным для чтения, но я все еще ищу любую информацию по этому поводу на странице документации.

]]>https://sla247.ru/forum/topic/663/нет-соединения-bfd-между-mpls-но-biz_internet-имеет-соединение-bfdRSS for NodeFri, 15 May 2026 08:36:11 GMTThu, 12 Feb 2026 14:32:21 GMT60Большое спасибо за подробный ответ. Я принимаю ваш ответ как решение, если, кроме изменения цвета, нет способа переопределить это поведение.

]]>https://sla247.ru/forum/post/4311https://sla247.ru/forum/post/4311Thu, 12 Feb 2026 14:32:25 GMT[M02@rt37]
Большое спасибо, что нашли время прочитать и ответить на вопрос, с которым я столкнулся в данной ситуации. Я видел руководства и документы с подобными сценариями, например, здесь https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/221734-configure-and-troubleshoot-sd-wan-networ.html где рекомендуется объявить подсеть расширения TLOC, которая в данном случае составляет
10.51.1.0/30
, MPLS SP через протокол маршрутизации, что в реальном мире вполне понятно. Спасибо за разъяснение части MPLS=no NAT, это было очень полезно.
В моей лаборатории eve-NG сеть MPLS, которую я использую, является частным облаком, и я подключился к пограничному маршрутизатору, который соединял Интернет, LTE и транспорты MPLS. Полагаю, что мне нужно запустить BGP и объявить там подсеть
10.51.1.0/30
, чтобы воспроизвести реальную ситуацию, или пока использовать другой нечастный цвет, как вы сказали. Мне также было интересно, есть ли какой-либо обходной путь, кроме изменения цвета или объявления подсети интерфейса расширения TLOC провайдеру MPLS, чтобы переопределить поведение по умолчанию natting на транспорте MPLS, чтобы не формировать сессию BFD? Еще
раз спасибо за ответ.

]]>https://sla247.ru/forum/post/4310https://sla247.ru/forum/post/4310Thu, 12 Feb 2026 14:32:24 GMTЗдравствуйте
[, @Nischal Prajapati] Спасибо за подробный пример использования. С моей точки зрения, следует избегать применения NAT к расширениям MPLS TLOC. Пусть MPLS-подслой передает частные транспортные IP-адреса между сайтами в исходном виде. Потому что фабрика SD-WAN предполагает, что
MPLS = частный = без NAT
. BFD ожидает увидеть исходный, непереведенный IP-адрес. Если NAT неизбежен, не используйте зарезервированный цвет «mpls». Вместо этого используйте настраиваемый цвет. Это позволит SDWAN обрабатывать соединение так, как если бы NAT был ожидаем, избегая «несоответствий bfd», которые вы видите... С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

]]>https://sla247.ru/forum/post/4309https://sla247.ru/forum/post/4309Thu, 12 Feb 2026 14:32:23 GMTЗдравствуйте
[, @Nischal Prajapati] Используйте настраиваемый цвет (custom 1). Это должно заставить SDWAN рассматривать путь как чувствительный к NAT и задействовать логику NAT-траверсала, чтобы BFD и туннели управления работали... https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/config-cmd.html#r_color_4875.xml Кроме того, для тестирования убедитесь, что ключевое слово restrict не добавлено в вашу команду color. Оно может незаметно блокировать формирование сеансов BFD, если удаленный сайт не имеет TLOC с точно таким же цветом, что затрудняет устранение неполадок, особенно когда все остальное (NAT...) выглядит нормально. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

]]>https://sla247.ru/forum/post/4308https://sla247.ru/forum/post/4308Thu, 12 Feb 2026 14:32:22 GMT