Ping del router o amfitrió VLAN: quina política PBR s’aplica?

La VLAN 10 hauria d’usar la VPN i la VLAN 20 la WAN, així que la primera prova és un ping des del router amb l’adreça d’interfície de la VLAN 10 com a origen. Funciona, els comptadors del route-map augmenten i tothom conclou que el disseny funciona. No és així. Aquest ping es va generar localment, i el trànsit generat localment arriba a un punt d’enganxament de política diferent d’un paquet que arriba a la interfície VLAN.

Tres condicions decideixen quina política estàs provant realment: on es crea el paquet, on entra i amb què coincideix.

On entra el paquet decideix quina política s’executa

Un route-map d’interfície associat amb ip policy route-map s’aplica als paquets que arriben a aquesta interfície, com descriu la guia PBR d’IOS XE. Un amfitrió de la VLAN 10 envia la seva petició, la trama arriba a la subinterfície VLAN i el router avalua la política allà. El paquet del propi router mai no arriba a aquesta interfície, perquè va néixer al router.

Triar l’adreça VLAN com a origen canvia la capçalera. No canvia l’origen.

Per què el ping amb origen encara no és l’amfitrió

L’adreça d’origen importa per a una coincidència ACL, i això és exactament el que fa tan convincent la prova. El paquet coincideix amb una clàusula d’origen, els comptadors augmenten i la sortida sembla correcta. El que la prova no pot mostrar és la interfície d’entrada, el context d’arribada o si un paquet de l’amfitrió prendria la mateixa branca.

Una prova que reprodueix la coincidència però no el context demostra la meitat del disseny, i amb mitja prova és com els dissenys surten amb la política equivocada enganxada.

Quan una política local és la resposta correcta

Cisco documenta ip local policy route-map per al trànsit que el router genera ell mateix. Aquest és un àmbit separat, i és l’eina correcta quan el requisit concerneix realment el trànsit propi del router. No és un pas que falti i que necessiti tot disseny d’encaminament VLAN. Una coincidència àmplia allà també pot afectar les connexions de gestió i de suport, cosa que és un canvi molt més gran del que sembla.

El TCP generat localment té un requisit previ addicional: necessita una entrada de destinació aplicable a la taula d’encaminament fins i tot quan la política selecciona un altre camí. Un resultat ICMP no demostra el mateix comportament per a TCP.

Què cal provar a l’amfitrió en lloc d’això

Executa la prova des d’un amfitrió autoritzat a la VLAN 10, amb la seva adreça d’origen, destinació, protocol i port reals. Registra la interfície d’entrada i la coincidència del route-map al costat del resultat, perquè l’evidència nomeni la política que es va executar. Després repeteix-ho per a un amfitrió de la VLAN 20 i confirma que pren l’altre camí.

Tots dos camins necessiten next hops funcionals, accessibilitat de retorn i, quan correspongui, cobertura VPN. PBR tria una decisió de reenviament; no crea el servei remot ni concedeix permís a l’aplicació.

Què pot i què no pot demostrar el resultat

Un flux d’amfitrió correcte demostra que la política va coincidir i que el camí triat va funcionar en aquell moment. No demostra que s’encamini el trànsit propi del router, ni demostra que l’aplicació estigués autoritzada, perquè són preguntes diferents amb proves diferents.

Conserva el ping al registre com a evidència sobre un paquet local. Després ves a obtenir l’evidència del flux de l’amfitrió, en lloc d’ampliar l’abast de la política fins que les dues proves semblin iguals.