Cisco SD-WAN NAT DIA переключается на определенные транспортные протоколы

[JUANNN]

Здравствуйте, В нашей компании мы пытаемся внедрить Cisco SD-WAN
NAT DIA на Service VPN 6136 только для потоков трафика из приложений O365 через локальный TLOC
общедоступного Интернета
.
У нас есть еще 2 транспорта: LTE (интернет-соединение с низкой пропускной способностью) и MPLS. Однако, поскольку VPN 6136 является корпоративным VPN, у нас включена
резервная
система
, поэтому, если публичный интернет TLOC становится недоступным, трафик O365 корпоративного VPN все равно может достичь своего назначения через центр обработки данных. Сложность возникает, когда мы хотим
контролировать
,
на какой TLOC переключается
резервный
вариант
. Когда происходит отказ и DIA недоступен в филиалах, для трафика O365 мы хотим переключиться на MPLS, чтобы трафик использовал такой транспорт для прохождения через SD-WAN Overlay до центра обработки данных. Для некоторых других потоков трафика мы хотим переключиться на LTE, также используя DIA. Можно ли настроить это с помощью централизованной политики данных,
используя ту же группу политик, в которой настроена DIA
, и добавить правило в политику трафика, которое соответствует трафику O365 и устанавливает локальное действие TLOC на MPLS TLOC? Или, как только поток трафика из O365 первоначально сопоставляется с последовательностью DIA (применяемой ранее), политика больше не обрабатывается в отношении потока трафика O365, и, если DIA недоступен через желаемый TLOC, он переключается на TLOC, выбранный маршрутизатором? Спасибо, Хуан

[Royalty]

Привет,
@JUANNN
, Я только что протестировал это на аппаратной лаборатории. Я не был бы удовлетворен результатами виртуального образа с такой сложностью 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.
Когда применяется централизованная политика, трафик выходит из интерфейса публичного Интернета GigabitEthernet0/0/1 и подсети 192.168.2.0/24 и подвергается NAT-преобразованию в подслой (проверено с помощью FIA и traceroute с ноутбука Windows). Этот выбор согласуется с результатами нескольких тестов подключения с различными кортежами идентификаторов потока.
При применении централизованной политики и отключении интерфейса публичного Интернета TLOC трафик выходит из интерфейса mpls TLOC GigabitEthernet0/0/2 и подсети 192.168.1.0/24 и проходит через оверлей в направлении маршрутизатора SDWAN Hub (проверено с помощью FIA и traceroute/ping с ноутбука Windows). Этот выбор снова остается неизменным при тестировании с несколькими кортежами потоков, например, с различными комбинациями исходных и конечных IP-адресов.
Когда применяется централизованная политика, а интерфейс 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]
Конфигурация политики централизованных данных трафика SD-WAN Частичный вывод трассировки FIA, когда все транспортные протоколы WAN (TLOC) работают: [Спойлер]
(Выделите, чтобы прочитать)
Пакет: 0 CBUG ID: 18
Сводка
Вход: GigabitEthernet0/1/0
Выход:
GigabitEthernet0/0/1
Состояние: FWD
Функция: IPV4(Вход)
Вход: GigabitEthernet0/1/0
Выход: <неизвестно>
Источник:
10.50.150.211
Пункт назначения:
8.8.8.4
Протокол: 1 (ICMP)
Функция: SDWAN Политика данных IN
VPN ID: 1999
VRF: 1
Название политики: DIA (CG:1)
Seq : 1
Флаги DNS : (0x0) НЕТ
Флаги политики : 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
От: Сторона службы
Действие: Перевод источника
Шаги: 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 нс
Пакет: 0 CBUG ID: 18СводкаВход: GigabitEthernet0/1/0Выход: GigabitEthernet0/0/1Состояние: FWDFeature: IPV4(Вход) Вход: GigabitEthernet0/1/0 Выход: <неизвестно> Источник: 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: [Спойлер]
(Выделите, чтобы прочитать)
Функция: IPV4(Вход)
Вход: GigabitEthernet0/1/0
Выход: <неизвестно>
Источник:
10.50.150.33
Пункт назначения:
8.8.8.8
Протокол: 1 (ICMP)
Функция: SDWAN Data Policy IN
VPN ID: 1999
VRF: 1
Название политики: DIA (CG:1)
Seq : 1
Флаги DNS : (0x0) НЕТ
Флаги политики : 0x240810
Флаги политики2: 0x0
Действие :
SET_LOCAL_TLOC Цвет 0x24 mpls, Encap ipsec
Фактический локальный цвет :
mpls
Действие :
REDIRECT_NAT
Действие :
NAT_FALLBACK
Особенность: SDWAN Пересылка
SDWAN adj OCE:
Выход:
GigabitEthernet0/0/2
Хеш-значение: 0xd2
Encap: ipsec
SLA: 0
SDWAN VPN: 1999
SDWAN Proto: IPV4
Out Label: 1008
Локальный цвет:
mpls
Удаленный цвет: biz-internet
FTM Tun ID: 415
SDWAN Session Info
SRC 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
Функция: IPV4(Вход) Вход: GigabitEthernet0/1/0 Выход: <неизвестно> Источник: 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 при отключении публичного Интернета
и
mpls: [Спойлер]
(Выделите, чтобы прочитать)
Пакет: 0 CBUG ID: 14
Сводка
Вход: GigabitEthernet0/1/0
Выход: Vlan666
Состояние:
DROP 483 (SdwanDataPolicyDrop)
Функция: Политика данных SDWAN IN
VPN ID: 1999
VRF: 1
Название политики: 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
Выход: <неизвестно>
Прошедшее время: 610 нс
Пакет: 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 Выход: <неизвестно> Прошедшее время: 610 нс В отладке FIA есть некоторые несоответствия, но в целом основные решения по пересылке пакетов, выходным интерфейсам и т. д. являются правильными. Однако вы утверждаете, что функция Fallback также зависит от «Local TLOC Action»? Да, я бы сказал, что на функцию Fallback влияет Local TLOC Action, и поэтому, даже если MPLS не поддерживает NAT, включение его в список Local TLOC с
Restrict + Fallback
означает, что публичный Интернет является предпочтительным, поскольку он может удовлетворить требованиям обеих политик, т. е. удовлетворяет требованиям как NAT VPN, так и Local TLOC, а не только одной из них: Local TLOC. Не будет ли трафик маршрутизироваться в соответствии с таблицей IP-маршрутизации соответствующего сервиса VPN после перехода на резервный вариант, который по умолчанию будет распределять нагрузку между всеми путями ECMP (MPLS и LTE)? По умолчанию, да, нагрузка будет распределена между всеми оставшимися путями ECMP.
Поскольку Restrict включен с опцией Fallback, маршрутизатору
запрещено
выбирать любой TLOC, который не входит в список Local TLOC. LTE не указан в списке, поэтому он полностью исключается из рассмотрения (даже во время перехода на резервный вариант). Опция restrict переопределяет «fallback», если указаны TLOC потому что вы включаете MPLS в список Local TLOC, чтобы обеспечить приоритет такого транспорта над другими, и в то же время, поскольку MPLS не поддерживает NAT, мы имеем гарантию, что он не будет использоваться в первую очередь для DIA, пока работает другой транспорт, указанный в действии Local TLOC
public internet
(который поддерживает NAT). Да, теоретически это ожидаемое поведение! На практике оно также работает таким образом.

[Kanan Huseynli]

Здравствуйте, у вас есть маршрут по умолчанию OMP как через MPLS и LTE, так и только через MPLS? В логике соответствия политикам, если какая-либо последовательность «соответствует», другие не проверяются (как в обычном списке доступа или карте маршрутов). Принимаются меры. В случае nat-dia > fallback происходит переход к маршрутизации. И если у вас есть маршрут по умолчанию только из MPLS, он перейдет только на MPLS. Надеюсь, это поможет.
Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.

[JUANNN]

У меня есть маршруты по умолчанию как для MPLS, так и для LTE.

[Kanan Huseynli]

Не уверен, сработает ли это. В настоящее время не могу проверить. Попробуйте использовать local-tloc с выбранными biz-internet и mpls. Но сделайте это во время MW и проведите полное тестирование, чтобы понять поведение. Надеюсь, это поможет.
Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.

[Royalty]

Привет,
@JUANNN
, Вероятно, сейчас уже слишком поздно, так что прошу прощения, но на случай, если это может пригодиться вам или кому-то еще... Чтобы ответить прямо на ваш вопрос, да, такой результат возможен, но из-за сложности это может вызвать проблемы в некоторых версиях, и поведение может измениться. Я настоятельно рекомендую проверить конфигурацию с помощью FIA (Feature Invocation Array), а НЕ Simulate Flows (или show sdwan policy service-path в CLI), так как это может дать ложную информацию, когда инженерия трафика выполняется с такой степенью детализации, о которой мы говорим. Должны быть руководства по использованию FIA, но я могу помочь, если понадобится. Лично я стараюсь свести инженерию трафика к минимуму, но все дело в том, чтобы найти правильный баланс. Это возможно с помощью следующей настройки: TLOC biz-internet, настроенный как интерфейс с поддержкой NAT
LTE TLOC, настроенный как интерфейс с поддержкой NAT
TLOC MPLS, настроенный с
отключенным
NAT Централизованная политика трафика данных или группа политик, настроенная следующим образом: Последовательность 1
Соответствие желаемому трафику, т. е. в данном случае приложениям Microsoft
Измените «Базовое действие» на «Принять» и выберите «NAT VPN» и «Локальный TLOC» в качестве действий
Установите флажок «Резервный вариант» для действия «NAT VPN»
Выберите «public-internet» и «mpls» в качестве цветов списка Local TLOC. Инкапсуляцию списка Local TLOC не нужно указывать, если это не GRE, так как IPSec является значением по умолчанию, но лучше указать ее, чтобы избежать проблем в будущих выпусках и обновлениях, где поведение по умолчанию изменится или неоднозначность будет обрабатываться по-другому.
Установите флажок «Ограничить» в действии списка Local TLOC. Это гарантирует, что трафик не будет использовать LTE и останется привязанным только к указанным TLOC. Действие
«Локальный TLOC» в сочетании с
действием
NAT VPN сообщает маршрутизатору, что он должен отдавать предпочтение выбранным TLOC, для которых трафик должен быть NAT. Необходимо использовать резервное копирование с ограничением. Параметр «Ограничить» ограничивает выбранные TLOC публичным Интернетом и mpls, одновременно блокируя использование LTE при любых обстоятельствах. Поскольку публичный Интернет поддерживает NAT, он является предпочтительным. Резервная опция позволяет использовать mpls-соединение, когда публичный Интернет не работает. Если публичный Интернет TLOC не работает, а опция резервного копирования не отмечена, трафик не может переключиться на mpls и будет отброшен. Последовательность 2 можно изменить по своему усмотрению, так как я не знаю, какого результата вы хотите достичь, когда LTE недоступен. С настройками, описанными и сконфигурированными ниже, LTE используется в приоритетном порядке, если он доступен. Если LTE недоступен, трафик будет NAT-преобразован в TLOC публичного Интернета. Если публичный Интернет недоступен, соответствующий трафик будет использовать MPLS в качестве последнего средства. Это связано с тем, что по умолчанию действие «NAT VPN» использует указанный TLOC, если он доступен. Если указанный TLOC в
действии
«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
Сопоставьте желаемый трафик, для которого требуется использование LTE.
Измените «Базовое действие» на «Принять» и выберите «NAT VPN» и «Локальный TLOC» в качестве действий.
Установите флажок «Резервный вариант» в действии «NAT VPN».
Выберите «LTE» в качестве цвета локального списка TLOC. Инкапсуляция локального списка TLOC не требует указания, если только это не GRE. IPSec является значением по умолчанию, но его лучше использовать, чтобы избежать проблем в будущих выпусках и обновлениях. Действие по умолчанию: Принять Номера последовательностей также можно менять, поскольку, хотя они, конечно, обрабатываются по порядку, используемые вами операторы соответствия, по-видимому, не пересекаются. Надеюсь, это помогло. Если есть вопросы, дайте мне знать!

[JUANNN]

Здравствуйте
[, @Royalty] Большое спасибо за ответ. К сожалению, в настоящее время я не могу протестировать это в лаборатории. Однако я хотел бы уточнить ваши утверждения: - Вы говорите: «
Выберите «public-internet» и «mpls» в качестве цветов локального списка TLOC
». Затем вы говорите:
«MPLS TLOC, настроенный с отключенным NAT».
Когда я проверил это в лаборатории, у меня был MPLS без включенного NAT, но в цветах локального списка TLOC у меня был только
public-internet
: Вот скриншот исходной политики, которая у меня была... ![JUANNN_0-1768986578646.png] Ваше предложение звучит интересно, потому что вы
включаете MPLS в локальный список TLOC
, чтобы обеспечить приоритет такого транспорта над другими,
и в то же время, поскольку MPLS не имеет включенного NAT, мы имеем гарантию, что он не будет использоваться в первую очередь для DIA, пока работает другой транспорт, указанный в локальном действии TLOC
public internet
(который имеет включенный NAT)
. Очевидно, что необходимо включить резервное действие NAT VPN. Это действительно выглядит как приемлемое решение, но у меня все еще есть к вам несколько вопросов: - Вы тестировали это, чтобы доказать его эффективность? Когда транспорт
публичного интернета
выходит из строя, запускается резервное копирование. Я знаю, после нескольких тестов, а также из книги Cisco Press о SD-WAN, что действие NAT VPN чувствительно к «локальному действию TLOC». Однако
вы утверждаете, что функция резервного переключения также чувствительна к «локальному действию TLOC»
? Разве трафик не будет маршрутизироваться в соответствии с таблицей IP-маршрутизации соответствующего сервиса VPN после резервного переключения, которое по умолчанию будет распределять нагрузку между всеми путями ECMP (MPLS и LTE)? Это необходимо обязательно проверить. Еще раз спасибо, Хуан