Ping do router fronte a host VLAN: que política PBR se aplica?

A VLAN 10 debería usar a VPN e a VLAN 20 a WAN, así que a primeira proba é un ping desde o router co enderezo de interface da VLAN 10 como orixe. Funciona, os contadores do route-map aumentan e todos conclúen que o deseño funciona. Non é así. Ese ping xerouse localmente, e o tráfico xerado localmente chega a un punto de enganche de política distinto dun paquete que chega á interface VLAN.

Tres condicións deciden que política estás probando realmente: onde se crea o paquete, onde entra e con que coincide.

O lugar onde entra o paquete decide que política se executa

Un route-map de interface asociado con ip policy route-map aplícase aos paquetes que chegan a esa interface, como describe a guía PBR de IOS XE. Un host na VLAN 10 envía a súa petición, a trama chega á subinterface VLAN e o router avalía a política alí. O paquete do propio router nunca chega a esa interface, porque naceu no router.

Escoller o enderezo VLAN como orixe cambia a cabeceira. Non cambia a orixe.

Por que o ping con orixe segue sen ser o host

O enderezo de orixe importa para unha coincidencia ACL, e iso é exactamente o que fai tan convincente a proba. O paquete coincide cunha cláusula de orixe, os contadores aumentan e a saída parece correcta. O que a proba non pode mostrar é a interface de entrada, o contexto de chegada ou se un paquete do host tomaría a mesma rama.

Unha proba que reproduce a coincidencia pero non o contexto demostra metade do deseño, e con media proba é como os deseños saen coa política equivocada asociada.

Cando unha política local é a resposta correcta

Cisco documenta ip local policy route-map para o tráfico que o router xera el mesmo. Ese é un alcance separado, e é a ferramenta correcta cando o requisito se refire de verdade ao tráfico propio do router. Non é un paso que falte e que necesite todo deseño de encamiñamento VLAN. Unha coincidencia ampla alí tamén pode afectar as conexións de xestión e de soporte, o que é un cambio moito maior do que parece.

O TCP xerado localmente ten un requisito previo adicional: necesita unha entrada de destino aplicable na táboa de encamiñamento mesmo cando a política selecciona outro camiño. Un resultado ICMP non demostra o mesmo comportamento para TCP.

Que probar no host no seu lugar

Executa a proba desde un host autorizado na VLAN 10, co seu enderezo de orixe, destino, protocolo e porto reais. Rexistra a interface de entrada e a coincidencia do route-map xunto ao resultado, para que a evidencia nomee a política que se executou. Despois repite para un host na VLAN 20 e confirma que toma o outro camiño.

Ambos os camiños necesitan next hops funcionais, accesibilidade de retorno e, cando corresponda, cobertura VPN. PBR escolle unha decisión de encamiñamento; non crea o servizo remoto nin concede permiso á aplicación.

Que pode e que non pode demostrar o resultado

Un fluxo de host correcto demostra que a política coincidiu e que o camiño escollido funcionou nese momento. Non demostra que se encamiñe o tráfico propio do router, nin demostra que a aplicación estivese autorizada, porque son preguntas distintas con probas distintas.

Conserva o ping no rexistro como evidencia sobre un paquete local. Despois vai buscar a evidencia do fluxo do host, en lugar de ampliar o alcance da política ata que as dúas probas parezan iguais.