Пінг маршрутизатора проти хоста 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 вибирає рішення про пересилання; він не створює віддалену службу й не надає застосунку дозвіл.

Що результат може й чого не може довести

Успішний потік хоста доводить, що політика збіглася й обраний шлях працював у той момент. Він не доводить, що трафік самого маршрутизатора спрямовується, і не доводить, що застосунок був авторизований, бо це різні питання з різними доказами.

Збережіть пінг у записі як доказ про локальний пакет. Потім ідіть по доказ потоку хоста, замість того щоб розширювати область політики, доки дві перевірки випадково не стануть схожими.