Пинг от рутера срещу хост 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 избира решение за препращане; той не създава отдалечената услуга и не дава разрешение на приложението.

Какво резултатът може и какво не може да докаже

Успешен поток на хост доказва, че политиката е съвпаднала и че избраният път е работил в този момент. Той не доказва, че трафикът на самия рутер се направлява, и не доказва, че приложението е било оторизирано, защото това са различни въпроси с различни доказателства.

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