Пинг роутера и хост VLAN: какая политика PBR действует?

VLAN 10 должен использовать VPN, а VLAN 20 — WAN, поэтому первая проверка — это пинг с роутера с адресом интерфейса VLAN 10 в качестве источника. Он проходит, счётчики route-map растут, и все делают вывод, что проект работает. Он не работает. Этот пинг был сгенерирован локально, а локально сгенерированный трафик попадает в другую точку привязки политики, чем пакет, приходящий на интерфейс VLAN.

Три условия определяют, какую политику вы на самом деле проверяете: где создаётся пакет, где он входит и чему соответствует.

Точка входа пакета определяет, какая политика выполняется

Route-map интерфейса, привязанная с помощью ip policy route-map, применяется к пакетам, приходящим на этот интерфейс, как описывает руководство по PBR для IOS XE. Хост в VLAN 10 отправляет запрос, кадр приходит на субинтерфейс VLAN, и роутер оценивает политику там. Собственный пакет роутера никогда не приходит на этот интерфейс, потому что он родился в роутере.

Выбор адреса VLAN в качестве источника меняет заголовок. Он не меняет происхождение.

Почему пинг с источником всё ещё не хост

Адрес источника важен для совпадения с ACL, и именно это делает проверку такой убедительной. Пакет совпадает с предложением источника, счётчики растут, и вывод выглядит правильным. Проверка не может показать входной интерфейс, контекст появления или то, выбрал бы пакет хоста ту же ветвь.

Проверка, которая воспроизводит совпадение, но не контекст, доказывает половину проекта, и именно с половиной доказательства проекты уходят в работу с неправильной политикой.

Когда локальная политика — правильный ответ

Cisco документирует ip local policy route-map для трафика, который роутер генерирует сам. Это отдельная область, и это правильный инструмент, когда требование действительно касается собственного трафика роутера. Это не недостающий шаг, который нужен каждому проекту управления VLAN. Широкое совпадение там также может затронуть управляющие и вспомогательные соединения, что является гораздо большим изменением, чем кажется.

У локально сгенерированного TCP есть дополнительное предварительное условие: ему нужна применимая запись назначения в таблице маршрутизации, даже когда политика выбирает другой путь. Результат ICMP не доказывает то же поведение для TCP.

Что вместо этого проверять на хосте

Запустите проверку с авторизованного хоста в VLAN 10, с его реальным адресом источника, назначением, протоколом и портом. Запишите входной интерфейс и совпадение route-map рядом с результатом, чтобы доказательство называло политику, которая выполнилась. Затем повторите для хоста в VLAN 20 и подтвердите, что он выбирает другой путь.

Оба пути нуждаются в работающих next hop, обратной достижимости и, где применимо, покрытии VPN. PBR выбирает решение о пересылке; он не создаёт удалённый сервис и не даёт приложению разрешение.

Что результат может и чего не может доказать

Успешный поток хоста доказывает, что политика совпала и выбранный путь работал в тот момент. Он не доказывает, что трафик самого роутера направляется, и не доказывает, что приложение было авторизовано, потому что это разные вопросы с разными доказательствами.

Сохраните пинг в записи как доказательство о локальном пакете. Затем идите за доказательством потока хоста, вместо того чтобы расширять область политики, пока две проверки случайно не станут похожи.