Ping del router frente a host VLAN: ¿qué política PBR se aplica?

VLAN 10 debería usar la VPN y VLAN 20 la WAN, así que la primera prueba es un ping desde el router con la dirección de interfaz de VLAN 10 como origen. Funciona, los contadores del route-map aumentan y todos concluyen que el diseño funciona. No es así. Ese ping se generó localmente, y el tráfico generado localmente llega a un punto de enganche de política distinto de un paquete que llega a la interfaz VLAN.

Tres condiciones deciden qué política estás probando en realidad: dónde se crea el paquete, dónde entra y con qué coincide.

Dónde entra el paquete decide qué política se ejecuta

Un route-map de interfaz asociado con ip policy route-map se aplica a los paquetes que llegan a esa interfaz, como describe la guía PBR de IOS XE. Un host de VLAN 10 envía su petición, la trama llega a la subinterfaz VLAN y el router evalúa la política allí. El paquete propio del router nunca llega a esa interfaz, porque nació en el router.

Elegir la dirección VLAN como origen cambia la cabecera. No cambia el origen.

Por qué el ping con origen sigue sin ser el host

La dirección de origen importa para una coincidencia ACL, y eso es exactamente lo que hace tan convincente la prueba. El paquete coincide con una cláusula de origen, los contadores aumentan y la salida parece correcta. Lo que la prueba no puede mostrar es la interfaz de entrada, el contexto de llegada o si un paquete del host tomaría la misma rama.

Una prueba que reproduce la coincidencia pero no el contexto demuestra la mitad del diseño, y con media prueba es como los diseños salen con la política equivocada asociada.

Cuándo una política local es la respuesta correcta

Cisco documenta ip local policy route-map para el tráfico que el propio router genera. Ese es un alcance separado, y es la herramienta correcta cuando el requisito se refiere de verdad al tráfico propio del router. No es un paso que falte y que todo diseño de direccionamiento VLAN necesite. Una coincidencia amplia allí también puede afectar a las conexiones de gestión y de soporte, lo que es un cambio mucho mayor de lo que parece.

El TCP generado localmente tiene un requisito previo adicional: necesita una entrada de destino aplicable en la tabla de rutas incluso cuando la política selecciona otra ruta. Un resultado ICMP no demuestra el mismo comportamiento para TCP.

Qué probar en el host en su lugar

Ejecuta la prueba desde un host autorizado en VLAN 10, con su dirección de origen, destino, protocolo y puerto reales. Registra la interfaz de entrada y la coincidencia del route-map junto al resultado, para que la evidencia nombre la política que se ejecutó. Luego repite para un host de VLAN 20 y confirma que toma la otra ruta.

Ambas rutas necesitan next hops que funcionen, accesibilidad de retorno y, cuando corresponda, cobertura VPN. PBR elige una decisión de reenvío; no crea el servicio remoto ni concede permiso a la aplicación.

Qué puede y qué no puede demostrar el resultado

Un flujo de host correcto demuestra que la política coincidió y que la ruta elegida funcionó en ese momento. No demuestra que se dirija el tráfico propio del router, ni demuestra que la aplicación estuviera autorizada, porque son preguntas distintas con pruebas distintas.

Conserva el ping en el registro como evidencia sobre un paquete local. Luego ve a obtener la evidencia del flujo del host, en lugar de ampliar el alcance de la política hasta que las dos pruebas se parezcan.