<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Cisco SD-WAN NAT DIA переключается на определенные транспортные протоколы]]></title><description><![CDATA[<p dir="auto">Здравствуйте, В нашей компании мы пытаемся внедрить Cisco SD-WAN<br />
NAT DIA на Service VPN 6136 только для потоков трафика из приложений O365 через локальный TLOC<br />
общедоступного Интернета<br />
.<br />
У нас есть еще 2 транспорта: LTE (интернет-соединение с низкой пропускной способностью) и MPLS. Однако, поскольку VPN 6136 является корпоративным VPN, у нас включена<br />
резервная<br />
система<br />
, поэтому, если публичный интернет TLOC становится недоступным, трафик O365 корпоративного VPN все равно может достичь своего назначения через центр обработки данных. Сложность возникает, когда мы хотим<br />
контролировать<br />
,<br />
на какой TLOC переключается<br />
резервный<br />
вариант<br />
. Когда происходит отказ и DIA недоступен в филиалах, для трафика O365 мы хотим переключиться на MPLS, чтобы трафик использовал такой транспорт для прохождения через SD-WAN Overlay до центра обработки данных. Для некоторых других потоков трафика мы хотим переключиться на LTE, также используя DIA. Можно ли настроить это с помощью централизованной политики данных,<br />
используя ту же группу политик, в которой настроена DIA<br />
, и добавить правило в политику трафика, которое соответствует трафику O365 и устанавливает локальное действие TLOC на MPLS TLOC? Или, как только поток трафика из O365 первоначально сопоставляется с последовательностью DIA (применяемой ранее), политика больше не обрабатывается в отношении потока трафика O365, и, если DIA недоступен через желаемый TLOC, он переключается на TLOC, выбранный маршрутизатором? Спасибо, Хуан</p>
]]></description><link>https://sla247.ru/forum/topic/607/cisco-sd-wan-nat-dia-переключается-на-определенные-транспортные-протоколы</link><generator>RSS for Node</generator><lastBuildDate>Fri, 15 May 2026 16:04:24 GMT</lastBuildDate><atom:link href="https://sla247.ru/forum/topic/607.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 12 Feb 2026 14:31:14 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Cisco SD-WAN NAT DIA переключается на определенные транспортные протоколы on Thu, 12 Feb 2026 14:31:20 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте<br />
[, <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/royalty" aria-label="Profile: Royalty">@<bdi>Royalty</bdi></a>] Большое спасибо за ответ. К сожалению, в настоящее время я не могу протестировать это в лаборатории. Однако я хотел бы уточнить ваши утверждения: - Вы говорите: «<br />
Выберите «public-internet» и «mpls» в качестве цветов локального списка TLOC<br />
». Затем вы говорите:<br />
«MPLS TLOC, настроенный с отключенным NAT».<br />
Когда я проверил это в лаборатории, у меня был MPLS без включенного NAT, но в цветах локального списка TLOC у меня был только<br />
public-internet<br />
: Вот скриншот исходной политики, которая у меня была... ![JUANNN_0-1768986578646.png] Ваше предложение звучит интересно, потому что вы<br />
включаете MPLS в локальный список TLOC<br />
, чтобы обеспечить приоритет такого транспорта над другими,<br />
и в то же время, поскольку MPLS не имеет включенного NAT, мы имеем гарантию, что он не будет использоваться в первую очередь для DIA, пока работает другой транспорт, указанный в локальном действии TLOC<br />
public internet<br />
(который имеет включенный NAT)<br />
. Очевидно, что необходимо включить резервное действие NAT VPN. Это действительно выглядит как приемлемое решение, но у меня все еще есть к вам несколько вопросов: - Вы тестировали это, чтобы доказать его эффективность? Когда транспорт<br />
публичного интернета<br />
выходит из строя, запускается резервное копирование. Я знаю, после нескольких тестов, а также из книги Cisco Press о SD-WAN, что действие NAT VPN чувствительно к «локальному действию TLOC». Однако<br />
вы утверждаете, что функция резервного переключения также чувствительна к «локальному действию TLOC»<br />
? Разве трафик не будет маршрутизироваться в соответствии с таблицей IP-маршрутизации соответствующего сервиса VPN после резервного переключения, которое по умолчанию будет распределять нагрузку между всеми путями ECMP (MPLS и LTE)? Это необходимо обязательно проверить. Еще раз спасибо, Хуан</p>
<p dir="auto"><img src="/forum/uploads/files/cisco/654db3b782d5d2c5a2a19f68751cae1cbdc37e10.png" alt="" class=" img-fluid img-markdown" /></p>
]]></description><link>https://sla247.ru/forum/post/3984</link><guid isPermaLink="true">https://sla247.ru/forum/post/3984</guid><dc:creator><![CDATA[JUANNN]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:20 GMT</pubDate></item><item><title><![CDATA[Reply to Cisco SD-WAN NAT DIA переключается на определенные транспортные протоколы on Thu, 12 Feb 2026 14:31:19 GMT]]></title><description><![CDATA[<p dir="auto">Привет,<br />
<a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/juannn" aria-label="Profile: JUANNN">@<bdi>JUANNN</bdi></a><br />
, Вероятно, сейчас уже слишком поздно, так что прошу прощения, но на случай, если это может пригодиться вам или кому-то еще... Чтобы ответить прямо на ваш вопрос, да, такой результат возможен, но из-за сложности это может вызвать проблемы в некоторых версиях, и поведение может измениться. Я настоятельно рекомендую проверить конфигурацию с помощью FIA (Feature Invocation Array), а НЕ Simulate Flows (или show sdwan policy service-path в CLI), так как это может дать ложную информацию, когда инженерия трафика выполняется с такой степенью детализации, о которой мы говорим. Должны быть руководства по использованию FIA, но я могу помочь, если понадобится. Лично я стараюсь свести инженерию трафика к минимуму, но все дело в том, чтобы найти правильный баланс. Это возможно с помощью следующей настройки: TLOC biz-internet, настроенный как интерфейс с поддержкой NAT<br />
LTE TLOC, настроенный как интерфейс с поддержкой NAT<br />
TLOC MPLS, настроенный с<br />
отключенным<br />
NAT Централизованная политика трафика данных или группа политик, настроенная следующим образом: Последовательность 1<br />
Соответствие желаемому трафику, т. е. в данном случае приложениям Microsoft<br />
Измените «Базовое действие» на «Принять» и выберите «NAT VPN» и «Локальный TLOC» в качестве действий<br />
Установите флажок «Резервный вариант» для действия «NAT VPN»<br />
Выберите «public-internet» и «mpls» в качестве цветов списка Local TLOC. Инкапсуляцию списка Local TLOC не нужно указывать, если это не GRE, так как IPSec является значением по умолчанию, но лучше указать ее, чтобы избежать проблем в будущих выпусках и обновлениях, где поведение по умолчанию изменится или неоднозначность будет обрабатываться по-другому.<br />
Установите флажок «Ограничить» в действии списка Local TLOC. Это гарантирует, что трафик не будет использовать LTE и останется привязанным только к указанным TLOC. Действие<br />
«Локальный TLOC» в сочетании с<br />
действием<br />
NAT VPN сообщает маршрутизатору, что он должен отдавать предпочтение выбранным TLOC, для которых трафик должен быть NAT. Необходимо использовать резервное копирование с ограничением. Параметр «Ограничить» ограничивает выбранные TLOC публичным Интернетом и mpls, одновременно блокируя использование LTE при любых обстоятельствах. Поскольку публичный Интернет поддерживает NAT, он является предпочтительным. Резервная опция позволяет использовать mpls-соединение, когда публичный Интернет не работает. Если публичный Интернет TLOC не работает, а опция резервного копирования не отмечена, трафик не может переключиться на mpls и будет отброшен. Последовательность 2 можно изменить по своему усмотрению, так как я не знаю, какого результата вы хотите достичь, когда LTE недоступен. С настройками, описанными и сконфигурированными ниже, LTE используется в приоритетном порядке, если он доступен. Если LTE недоступен, трафик будет NAT-преобразован в TLOC публичного Интернета. Если публичный Интернет недоступен, соответствующий трафик будет использовать MPLS в качестве последнего средства. Это связано с тем, что по умолчанию действие «NAT VPN» использует указанный TLOC, если он доступен. Если указанный TLOC в<br />
действии<br />
«Local TLOC» недоступен, используйте любой другой интерфейс с поддержкой NAT. Если отмечена опция «fallback» и нет других интерфейсов с поддержкой NAT, используйте таблицу маршрутизации и любые оставшиеся пути. Если вы предпочитаете, чтобы трафик отбрасывался при недоступности LTE, используйте приведенную ниже конфигурацию, но с отмеченной опцией «restrict» и снятой отметкой «fallback». Может быть интересно знать, что опция restrict переопределяет опцию fallback, например, если только LTE указан в качестве цвета списка Local TLOC с отмеченными опциями restrict и fallback, то при недоступности LTE трафик будет отклонен. Однако лучше отменить выбор опции fallback, чтобы избежать конфликтов с более поздними версиями программного обеспечения. Если вы хотите, чтобы маршрутизатор переходил на MPLS, когда LTE недоступен, выберите MPLS в качестве дополнительного цвета локального списка TLOC и отметьте «fallback» с отмеченной опцией «restrict», что в основном соответствует последовательности 1. Последовательность 2<br />
Сопоставьте желаемый трафик, для которого требуется использование LTE.<br />
Измените «Базовое действие» на «Принять» и выберите «NAT VPN» и «Локальный TLOC» в качестве действий.<br />
Установите флажок «Резервный вариант» в действии «NAT VPN».<br />
Выберите «LTE» в качестве цвета локального списка TLOC. Инкапсуляция локального списка TLOC не требует указания, если только это не GRE. IPSec является значением по умолчанию, но его лучше использовать, чтобы избежать проблем в будущих выпусках и обновлениях. Действие по умолчанию: Принять Номера последовательностей также можно менять, поскольку, хотя они, конечно, обрабатываются по порядку, используемые вами операторы соответствия, по-видимому, не пересекаются. Надеюсь, это помогло. Если есть вопросы, дайте мне знать!</p>
]]></description><link>https://sla247.ru/forum/post/3983</link><guid isPermaLink="true">https://sla247.ru/forum/post/3983</guid><dc:creator><![CDATA[Royalty]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:19 GMT</pubDate></item><item><title><![CDATA[Reply to Cisco SD-WAN NAT DIA переключается на определенные транспортные протоколы on Thu, 12 Feb 2026 14:31:18 GMT]]></title><description><![CDATA[<p dir="auto">Не уверен, сработает ли это. В настоящее время не могу проверить. Попробуйте использовать local-tloc с выбранными biz-internet и mpls. Но сделайте это во время MW и проведите полное тестирование, чтобы понять поведение. Надеюсь, это поможет.<br />
Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.</p>
]]></description><link>https://sla247.ru/forum/post/3982</link><guid isPermaLink="true">https://sla247.ru/forum/post/3982</guid><dc:creator><![CDATA[Kanan Huseynli]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:18 GMT</pubDate></item><item><title><![CDATA[Reply to Cisco SD-WAN NAT DIA переключается на определенные транспортные протоколы on Thu, 12 Feb 2026 14:31:17 GMT]]></title><description><![CDATA[<p dir="auto">У меня есть маршруты по умолчанию как для MPLS, так и для LTE.</p>
]]></description><link>https://sla247.ru/forum/post/3981</link><guid isPermaLink="true">https://sla247.ru/forum/post/3981</guid><dc:creator><![CDATA[JUANNN]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:17 GMT</pubDate></item><item><title><![CDATA[Reply to Cisco SD-WAN NAT DIA переключается на определенные транспортные протоколы on Thu, 12 Feb 2026 14:31:16 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте, у вас есть маршрут по умолчанию OMP как через MPLS и LTE, так и только через MPLS? В логике соответствия политикам, если какая-либо последовательность «соответствует», другие не проверяются (как в обычном списке доступа или карте маршрутов). Принимаются меры. В случае nat-dia &gt; fallback происходит переход к маршрутизации. И если у вас есть маршрут по умолчанию только из MPLS, он перейдет только на MPLS. Надеюсь, это поможет.<br />
Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.</p>
]]></description><link>https://sla247.ru/forum/post/3980</link><guid isPermaLink="true">https://sla247.ru/forum/post/3980</guid><dc:creator><![CDATA[Kanan Huseynli]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:16 GMT</pubDate></item><item><title><![CDATA[Reply to Cisco SD-WAN NAT DIA переключается на определенные транспортные протоколы on Thu, 12 Feb 2026 14:31:15 GMT]]></title><description><![CDATA[<p dir="auto">Привет,<br />
<a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/juannn" aria-label="Profile: JUANNN">@<bdi>JUANNN</bdi></a><br />
, Я только что протестировал это на аппаратной лаборатории. Я не был бы удовлетворен результатами виртуального образа с такой сложностью TE. Я провел тестирование на C8200L-1N-4T с версией 17.09.05 и на другом C8200L-1N-4T с версией 17.12.05a. Версии контроллера не должны иметь значения, поскольку структура политики остается неизменной независимо от версии SD-WAN Manager (vManage) и контроллера (vSmart). Фактическая обработка политики и принятие решений осуществляются на IOS-XE WAN Edge, поэтому это, вероятно, будет определяющим фактором при работе с различными версиями программного обеспечения. Однако стоит отметить, что компоненты контроллера в этой лаборатории работают под управлением версии 20.12.4. Вот мои результаты: Когда все три интерфейса работают и централизованная политика не применяется, трафик распределяется между тремя TLOC (mpls, LTE, public-internet) в направлении маршрутизатора SDWAN Hub, рекламирующего маршрут по умолчанию 0.0.0.0/0.<br />
Когда применяется централизованная политика, трафик выходит из интерфейса публичного Интернета GigabitEthernet0/0/1 и подсети 192.168.2.0/24 и подвергается NAT-преобразованию в подслой (проверено с помощью FIA и traceroute с ноутбука Windows). Этот выбор согласуется с результатами нескольких тестов подключения с различными кортежами идентификаторов потока.<br />
При применении централизованной политики и отключении интерфейса публичного Интернета TLOC трафик выходит из интерфейса mpls TLOC GigabitEthernet0/0/2 и подсети 192.168.1.0/24 и проходит через оверлей в направлении маршрутизатора SDWAN Hub (проверено с помощью FIA и traceroute/ping с ноутбука Windows). Этот выбор снова остается неизменным при тестировании с несколькими кортежами потоков, например, с различными комбинациями исходных и конечных IP-адресов.<br />
Когда применяется централизованная политика, а интерфейс TLOC публичного Интернета и интерфейс TLOC mpls отключены, трафик отбрасывается (проверено с помощью FIA и traceroute/ping с ноутбука Windows) и не выходит из интерфейса LTE TLOC GigabitEthernet0/0/0 в подсети 192.168.3.0/24. Это снова подтверждается при тестировании с несколькими кортежами потоков, например, с различными комбинациями IP-адресов источника и назначения. На интерфейсах WAN/Transport включена/отключена функция NAT в соответствии с настройками, указанными в предыдущем посте. Тестирование проводилось с нескольких исходных адресов в пределах 10.50.150.0/24 по нескольким IP-адресам в 8.8.8.0/24. Это гарантирует, что поведение применяется последовательно в соответствии с политикой, а не в результате случайного выбора ECMP пути, который мы в любом случае ожидали бы. Конфигурация политики следующая: ![SD-WAN Centralised Traffic Data Policy Configuration]<br />
Конфигурация политики централизованных данных трафика SD-WAN Частичный вывод трассировки FIA, когда все транспортные протоколы WAN (TLOC) работают: [Спойлер]<br />
(Выделите, чтобы прочитать)<br />
Пакет: 0 CBUG ID: 18<br />
Сводка<br />
Вход: GigabitEthernet0/1/0<br />
Выход:<br />
GigabitEthernet0/0/1<br />
Состояние: FWD<br />
Функция: IPV4(Вход)<br />
Вход: GigabitEthernet0/1/0<br />
Выход: &lt;неизвестно&gt;<br />
Источник:<br />
10.50.150.211<br />
Пункт назначения:<br />
8.8.8.4<br />
Протокол: 1 (ICMP)<br />
Функция: SDWAN Политика данных IN<br />
VPN ID: 1999<br />
VRF: 1<br />
Название политики: DIA (CG:1)<br />
Seq : 1<br />
Флаги DNS : (0x0) НЕТ<br />
Флаги политики : 0x240810<br />
Флаги политики2: 0x0<br />
Действие :<br />
SET_LOCAL_TLOC Цвет 0x20 public-internet, Encap ipsec<br />
Фактический локальный цвет :<br />
Неопределенное<br />
действие:<br />
REDIRECT_NAT<br />
Действие:<br />
NAT_FALLBACK<br />
Функция: NAT<br />
VRFID: 1<br />
table-id: 1<br />
Протокол: ICMP<br />
Направление: IN to OUT<br />
От: Сторона службы<br />
Действие: Перевод источника<br />
Шаги: SESS-CREATE<br />
Идентификатор совпадения: 2<br />
Старый адрес:<br />
10.50.150.211<br />
Новый адрес:<br />
192.168.2.10<br />
Исходный порт источника: 1<br />
Новый порт источника: 1<br />
Исходный порт назначения: 1<br />
Новый порт назначения: 1<br />
Функция: IPV4_NAT_OUTPUT_FIA<br />
Запись: Выход - 0x81516764<br />
Вход: Vlan666<br />
Выход:<br />
GigabitEthernet0/0/1 (public-internet)<br />
Прошедшее время: 271280 нс<br />
Пакет: 0 CBUG ID: 18СводкаВход: GigabitEthernet0/1/0Выход: GigabitEthernet0/0/1Состояние: FWDFeature: IPV4(Вход) Вход: GigabitEthernet0/1/0 Выход: &lt;неизвестно&gt; Источник: 10.50.150.211 Назначение: 8.8.8.4 Протокол: 1 (ICMP) Функция: SDWAN Политика данных INVPN ID: 1999 VRF: 1 Название политики: DIA (CG:1)Seq : 1 Флаги DNS : (0x0) NONE Флаги политики : 0x240810 Флаги политики 2: 0x0 Действие : SET_LOCAL_TLOC Цвет 0x20 public-internet, Encap ipsec Фактический локальный цвет : Неопределенное действие: REDIRECT_NAT Действие: NAT_FALLBACK Функция: NAT VRFID: 1 table-id: 1 Протокол: ICMP Направление: IN to OUT From: Сторона службы Действие: Перевод источника Шаги: SESS-CREATE Идентификатор совпадения: 2 Старый адрес: 10.50.150.211 Новый адрес: 192.168.2.10 Исходный порт: 1 Новый порт: 1 Исходный порт назначения: 1 Новый порт назначения: 1 Функция: IPV4_NAT_OUTPUT_FIA Вход: Выход - 0x81516764 Вход: Vlan666 Выход: GigabitEthernet0/0/1 (public-internet)Прошедшее время: 271280 нс Частичный вывод трассировки FIA при отключении public-internet: [Спойлер]<br />
(Выделите, чтобы прочитать)<br />
Функция: IPV4(Вход)<br />
Вход: GigabitEthernet0/1/0<br />
Выход: &lt;неизвестно&gt;<br />
Источник:<br />
10.50.150.33<br />
Пункт назначения:<br />
8.8.8.8<br />
Протокол: 1 (ICMP)<br />
Функция: SDWAN Data Policy IN<br />
VPN ID: 1999<br />
VRF: 1<br />
Название политики: DIA (CG:1)<br />
Seq : 1<br />
Флаги DNS : (0x0) НЕТ<br />
Флаги политики : 0x240810<br />
Флаги политики2: 0x0<br />
Действие :<br />
SET_LOCAL_TLOC Цвет 0x24 mpls, Encap ipsec<br />
Фактический локальный цвет :<br />
mpls<br />
Действие :<br />
REDIRECT_NAT<br />
Действие :<br />
NAT_FALLBACK<br />
Особенность: SDWAN Пересылка<br />
SDWAN adj OCE:<br />
Выход:<br />
GigabitEthernet0/0/2<br />
Хеш-значение: 0xd2<br />
Encap: ipsec<br />
SLA: 0<br />
SDWAN VPN: 1999<br />
SDWAN Proto: IPV4<br />
Out Label: 1008<br />
Локальный цвет:<br />
mpls<br />
Удаленный цвет: biz-internet<br />
FTM Tun ID: 415<br />
SDWAN Session Info<br />
SRC IP:<br />
192.168.1.35 (IP-адрес интерфейса MPLS)<br />
Порт SRC: 12346 IP<br />
DST:<br />
86.86.86.86 (публичный IP SDWAN Hub)<br />
Порт DST: 12426 IP<br />
удаленной системы:<br />
10.100.100.1 (SDWAN Hub)<br />
Тип поиска: TUN_DEMUX<br />
Тип службы: NONE<br />
Функция: IPV4(Вход) Вход: GigabitEthernet0/1/0 Выход: &lt;неизвестно&gt; Источник: 10.50.150.33 Пункт назначения: 8.8.8.8 Протокол: 1 (ICMP) Функция: SDWAN Data Policy INVPN ID: 1999 VRF: 1 Название политики: DIA (CG:1)Seq : 1 Флаги DNS : (0x0) NONE Флаги политики : 0x240810 Флаги политики 2: 0x0 Действие : SET_LOCAL_TLOC Цвет 0x24 mpls, Encap ipsec Фактический локальный цвет : mpls Действие : REDIRECT_NAT Действие : NAT_FALLBACKFeature: SDWAN ForwardingSDWAN adj OCE:Output : GigabitEthernet0/0/2Hash Value : 0xd2Encap : ipsecSLA : 0SDWAN VPN : 1999SDWAN Proto : IPV4Out Label : 1008Local Color : mplsRemote Color : biz-internetFTM Tun ID : 415SDWAN Session InfoSRC IP : 192.168.1.35 (IP-адрес интерфейса MPLS) Порт SRC: 12346 IP DST: 86.86.86.86 (публичный IP-адрес SDWAN Hub) Порт DST: 12426 IP удаленной системы: 10.100.100.1 (SDWAN Hub) Тип поиска: TUN_DEMUX Тип службы: NONE Частичный вывод трассировки FIA при отключении публичного Интернета<br />
и<br />
mpls: [Спойлер]<br />
(Выделите, чтобы прочитать)<br />
Пакет: 0 CBUG ID: 14<br />
Сводка<br />
Вход: GigabitEthernet0/1/0<br />
Выход: Vlan666<br />
Состояние:<br />
DROP 483 (SdwanDataPolicyDrop)<br />
Функция: Политика данных SDWAN IN<br />
VPN ID: 1999<br />
VRF: 1<br />
Название политики: DIA (CG:1)<br />
Seq : 1<br />
Флаги DNS : (0x0) NONE<br />
Флаги политики : 0x240810<br />
Флаги политики2: 0x0<br />
Действие :<br />
SET_LOCAL_TLOC Цвет 0x24 mpls, Encap ipsec<br />
Фактический локальный цвет :<br />
Неопределенное<br />
действие: REDIRECT_NAT<br />
Действие: NAT_FALLBACK<br />
Функция:<br />
INPUT_DROP<br />
Запись: Вход - 0x814dcfbc<br />
Вход: Vlan666<br />
Выход: &lt;неизвестно&gt;<br />
Прошедшее время: 610 нс<br />
Пакет: 0 CBUG ID: 14SummaryInput : GigabitEthernet0/1/0Output : Vlan666State : DROP 483 (SdwanDataPolicyDrop)Feature: SDWAN Data Policy INVPN ID : 1999VRF : 1Policy Name : DIA (CG:1)Seq: 1 Флаги DNS: (0x0) NONE Флаги политики: 0x240810 Флаги политики 2: 0x0 Действие: SET_LOCAL_TLOC Цвет 0x24 mpls, Encap ipsec Фактический локальный цвет: Неопределенное действие: REDIRECT_NAT Действие: NAT_FALLBACK Функция: INPUT_DROP Запись: Вход — 0x814dcfbc Вход: Vlan666 Выход: &lt;неизвестно&gt; Прошедшее время: 610 нс В отладке FIA есть некоторые несоответствия, но в целом основные решения по пересылке пакетов, выходным интерфейсам и т. д. являются правильными. Однако вы утверждаете, что функция Fallback также зависит от «Local TLOC Action»? Да, я бы сказал, что на функцию Fallback влияет Local TLOC Action, и поэтому, даже если MPLS не поддерживает NAT, включение его в список Local TLOC с<br />
Restrict + Fallback<br />
означает, что публичный Интернет является предпочтительным, поскольку он может удовлетворить требованиям обеих политик, т. е. удовлетворяет требованиям как NAT VPN, так и Local TLOC, а не только одной из них: Local TLOC. Не будет ли трафик маршрутизироваться в соответствии с таблицей IP-маршрутизации соответствующего сервиса VPN после перехода на резервный вариант, который по умолчанию будет распределять нагрузку между всеми путями ECMP (MPLS и LTE)? По умолчанию, да, нагрузка будет распределена между всеми оставшимися путями ECMP.<br />
Поскольку Restrict включен с опцией Fallback, маршрутизатору<br />
запрещено<br />
выбирать любой TLOC, который не входит в список Local TLOC. LTE не указан в списке, поэтому он полностью исключается из рассмотрения (даже во время перехода на резервный вариант). Опция restrict переопределяет «fallback», если указаны TLOC потому что вы включаете MPLS в список Local TLOC, чтобы обеспечить приоритет такого транспорта над другими, и в то же время, поскольку MPLS не поддерживает NAT, мы имеем гарантию, что он не будет использоваться в первую очередь для DIA, пока работает другой транспорт, указанный в действии Local TLOC<br />
public internet<br />
(который поддерживает NAT). Да, теоретически это ожидаемое поведение! На практике оно также работает таким образом.</p>
<p dir="auto"><img src="/forum/uploads/files/cisco/8db32eedf6a1cbe59483d632882e791766a8af66.png" alt="" class=" img-fluid img-markdown" /></p>
]]></description><link>https://sla247.ru/forum/post/3979</link><guid isPermaLink="true">https://sla247.ru/forum/post/3979</guid><dc:creator><![CDATA[Royalty]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:15 GMT</pubDate></item></channel></rss>