утечка маршрута между VPN через топологию

[dijix1990]

У меня есть утечка маршрутизатора между VPN через топологию - действие «экспорт в» утечка между VPN1 (HUB DC) и VPN 10-11,13,15 (BRANCHES) vpn-list VPN-export-from-Branch-to-DC vpn 10-11 vpn 13 vpn 15 vpn-list VPN-export-from-DC-to-Branch vpn 1 vpn-list VPN-import-to-Branch vpn 10-11 vpn 13 vpn 15 vpn-list VPN-import-to-DC vpn 1 control-policy Topology-vpn-export-from-DC-to-branch sequence 1 match route vpn-list VPN-export-from-DC-to-Branch prefix-list _AnyIpv4PrefixList ! action accept export-to vpn-list VPN-import-to-Branch ! ! default-action accept control-policy Topology-vpn-export-from-branch-to-DC sequence 1 match route vpn-list VPN-export-from-Branch-to-DC prefix-list _AnyIpv4PrefixList ! action accept export-to vpn-list VPN-import-to-DC ! ! default-action accept и он работает как обычно. Несколько дней назад я хотел добавить новую последовательность для VPN16, но для новой
последовательности 11
она не работает. control-policy Topology-vpn-export-from-DC-to-branch sequence 1 match route vpn-list VPN-export-from-DC-to-Branch prefix-list _AnyIpv4PrefixList ! action accept export-to vpn-list VPN-import-to-Branch ! ! sequence 11 match route vpn-list VPN-export-from-DC-to-Branch prefix-list _AnyIpv4PrefixList ! action accept export-to vpn-list VPN16-Branch-WiFi ! ! default-action accept ! control-policy Topology-vpn-export-from-branch-to-DC sequence 1 match route vpn-list VPN-export-from-Branch-to-DC prefix-list _AnyIpv4PrefixList ! action accept export-to vpn-list VPN-import-to-DC ! ! sequence 11 match route vpn-list VPN16-Branch-WiFi prefix-list _AnyIpv4PrefixList ! action accept export-to vpn-list VPN-import-to-DC ! ! default-action accept ! Почему это происходит? Могу ли я использовать некоторые последовательности для утечки? Если я добавляю vpn16 в списки vpn
VPN-export-from-Branch-to-DC и VPN-import-to-Branch,
утечка работает

[M02@rt37]

Мммм, хорошо
@dijix1990 Итак, вам нужно настроить конфигурацию, чтобы избежать пересечения совпадений в последовательности 1 и последовательности 11. Один из подходов заключается в использовании более конкретных критериев в последовательности 11, таких как специальный список vpn-list или prefix-list для VPN16, чтобы обеспечить отсутствие пересечения с маршрутами VPN1, обрабатываемыми в последовательности 1. В качестве альтернативы вы можете разделить обработку VPN1 на отдельные списки vpn, один для VPN10-11,13,15, а другой для VPN16, обеспечив, чтобы каждая последовательность имела свой собственный набор маршрутов для обработки. Это гарантирует, что последовательность 11 будет оцениваться для трафика, специфичного для VPN16, без вмешательства со стороны последовательности 1. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[M02@rt37]

Здравствуйте
[, @dijix1990] Политики управления обрабатывают последовательности в том порядке, в котором они настроены. Если маршрут соответствует критериям в более ранней последовательности, выполняется соответствующее действие, а последующие последовательности игнорируются. Таким образом, в вашем случае маршруты, соответствующие последовательности 1 в
Topology-vpn-export-from-DC-to-branch
политике обрабатываются там, поэтому они не достигают последовательности 11. Такое поведение ожидаемо в конфигурациях, основанных на политике. Кроме того, проблема возникает из-за того, что vpn16 явно не включен в
VPN-export-from-Branch-to-DC
или
VPN-import-to-Branch
. В результате vpn16 не соответствует операции export-to, если он не добавлен в vpn-list, используемый в последовательности 1. Если списки VPN в последовательности 1 уже обрабатывают маршруты, предназначенные для vpn16, добавление новой последовательности для него не сработает, если не будет скорректирована логика последовательности. При добавлении vpn16
в существующие списки VPN, такие как
VPN-export-from-Branch-to-DC
и
VPN-import-to-Branch
, он становится частью процесса сопоставления в последовательности 1. Таким образом, действие export-to работает без необходимости создания отдельной последовательности для vpn16. Этот подход работает, потому что логика утечки маршрутов применяется ко всем VPN в списках, включая vpn16. Вам необходимо настроить критерии сопоставления в новой последовательности. Это может включать использование специального списка vpn-list для vpn16, который не пересекается со списками, используемыми в последовательности 1. Вы также можете изменить список prefix-list или убедиться, что маршруты vpn16 не совпадают с более ранними последовательностями. Таким образом, vpn16 может обрабатываться независимо, без обработки последовательностью 1. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.

[dijix1990]

Это странная логика, потому что это не та же последовательность Vpn 10-11,13,15 + vpn 1 И Vpn 16 + 1 vpn Для меня это ненормальная логика, критерии соответствия разные Для политики данных я могу использовать разные последовательности, и это работает правильно

[MHM Cisco World]

Извините, почему вы используете термин «утечка»? Утечка происходит в одном маршрутизаторе, в SDWAN между двумя пирами нет утечки
VPN x - OMP - VPN y
OMP Как я могу назвать это универсальным, для чего мы можем получать префикс от разных VPN ? Что касается проблемы, попробуйте изменить порядок
MHM.

[dijix1990]

Это тот же процесс, он происходит на vSmart, все префиксы из одного vpn экспортируются в другой vpn.